[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CDPATH reports to stdout and even non-interactively

From: Geoff Kuenning
Subject: Re: CDPATH reports to stdout and even non-interactively
Date: Fri, 15 Aug 2008 19:12:03 -0500

>> Description:
>>      If CDPATH is set, whenever bash changes directories to a
>>      non-absolute path it reports the new directory to stdout.
>>      This is done even if bash is running in non-interactive mode,
>>      such as in a script.  That breaks scripts that do things like
>>      this:
> This is the behavior that Posix requires:  when CDPATH is used, bash
> outputs the name of the new working directory to stdout.  Commands
> and shell functions need to take this into account.

Actually, the Posix standard is ambiguous.  Although it (foolishly)
requires reporting to stdout rather than stderr, it does not mention
whether this behavior is required for both interactive and
non-interactive shells.

When the Posix standard is ambiguous or just plain wrong, it's better
to work to change or clarify it than to guess and to slavishly follow

In the current case, it's clearly incorrect to report the new working
directory, which is intended as feedback to humans, to stdout.  So the
Posix standard should be changed in the next revision.

> The man page and info doc should list all of the shell variables that
> affect bash's behavior.  If that's not the case, please report it.

In other words, "If a sneaky security hole is documented by
implication in the 5000-line man page, there is no need to close the
hole."  A better approach is to take an attitude of "To the extent
possible, shell script writers should be able to write secure scripts
without worrying about obscure interactions between their script and
the invoking environment."

> As for IFS, the shell does reset it to " \t\n" at startup (which I
> cribbed from the Korn shell).  That's why bash scripts don't reset
> it themselves.

See the above.  Dave Korn added that feature because of all the
security holes introduced by IFS, which definitely falls into the
"obscure interactions".  We're smarter about that sort of stuff now
than when Steve Bourne wrote the original sh; we should be trying to
minimize that kind of thing rather than maximize it.

> If by (4) you mean that the shell should ignore variables from the
> environment when it starts up in non-interactive mode, there will have
> to be a very good case made to introduce this level of backwards
> incompatibility.  That case hasn't been made yet.

I don't mean that the shell should ignore ALL environment variables;
that would break a ton of scripts.  Even ignoring PATH would be a Very
Bad Thing, since we've long ago grown used to inheriting PATH.

What I meant was that we should audit the inherited variables, and
make an intelligent and informed decision about each on a case-by-case
basis.  See below for suggestions.

> (And the CDPATH issue has come up before.  Several times.)

That's a sign that there's a real problem here.

Here's an analysis of all the document environment variables.  I'll
only mention variables that might be risky from a security standpoint

    BASH_ENV    is the cracker's delight.  Any setuid program that
                invokes a Bash script, even indirectly, is completely
                open to attack.  I can't see any way to make this
                feature safe, although it would certainly help to deny
                it if the UID is zero (but there are sensitive
                non-root accounts that could still be attacked).  It's
                worth noting that BASH_ENV has been used in cracks in
                the past.

    CDPATH      Should be unset in non-interactive mode.  Scripts are
                unlikely to want to inherit CDPATH; if they want to
                use it they can easily set it themselves.

    GLOBIGNORE  Should be unset in non-interactive mode.  I can't come
                up with a crack in 10 seconds, but I'm confident that
                within 30 minutes I could figure out a way to abuse a
                script by controlling its globbing.

    HOME        Might be abusable, but as with PATH, scripts generally
                assume it's untrusted.

    IFS         Already being reset

    IGNOREEOF   Already ignored in non-interactive shells (and another
                example of where we had to learn the hard way).

    MAIL        Should be ignored in non-interactive mode (and
                probably already is).

    OPTERR      It's worth noting that bash gets this one right.  In
                other words, there's precedent for handling other
                variables correctly.

    PATH        Well known, so OK.

                I'm not sure about the security implications of this
                one, because I don't know everything it changes.
                Superficially, it seems OK, but somebody more
                knowledgeable about all its effects should spend some
                time thinking about how to crack a script by
                manipulating it.

    TMPDIR      This one is pretty well known.  It's abusable, but
                removing it would be pretty bad for backwards
    Geoff Kuenning   address@hidden   http://www.cs.hmc.edu/~geoff/

The P in "PDF" is a lie.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]