Re: Bash-4.3 Official Patch 27
Linda Walsh wrote: > wrote: > > The change only affects environment variables **loaded as exported > > functions**. Bash won't forbid you from using / inside the name of an > > environment variables. > > > > The below doesn't demonstrate bash doing anything with the variable you > declared. > > You declare an ENV var with 'env' (not part of bash), then you start a new > shell and use env to see that the original value is still there. It > should be. > > You are not demonstrating any interaction with BASH. I was precisely trying to demostrate that bash wasn't doing anything. I got the impression that becker/Jon? was claiming that with Patch 27 (which removes those variable with a slash from loading as functions), variables with a / were removed from the environment. After rereading the subthread, I think I may have misunderstood them.
Re: Bash-4.3 Official Patch 27
2014-09-27 22:48:44 -0600, Eric Blake:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> > BASH PATCH REPORT
> > =
>
> > /* Don't import function names that are invalid identifiers from the
> > environment, though we still allow them to be defined as shell
> > variables. */
> > ! if (absolute_program (tname) == 0 && (posixly_correct == 0 ||
> > legal_identifier (tname)))
> > ! parse_and_execute (temp_string, tname,
> > SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
>
> This patch forbids importing function names containing '/' (yay!), and
> we already established that bash has never been able to properly import
> functions with names containing '='. But I'm assuming there will need
> to be a followup patch to actually reject the attempt to create such
> function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
> issue an error message instead of printing "oops"), so that we do not
> have the confusing situation of being unable to pass all permitted
> function names through an export/import cycle.
[...]
I'd say it's unfortunate that the fix for CVE-2014-6271 removes
the support for exporting functions with slash in their name.
functions share the same namespace as other commands (and not as
variables which is also why the original implementation of
function exports was flawed/inconsistent), so it would make
sense to allow any name for a function.
Exported functions was a usefully debugging tool. You could do
things like:
env rm='() { [ "$1" = want-to-keep ] || command rm "$@"; }
' /bin/rm='() { [ "$1" != want-to-keep ] && command rm "$@"; }
' my-command
To avoid want-to-keep be removed by my-command eventually
running system("/bin/rm want-to-keep").
I guess I'll have to switch to zsh now (using $ZDOTDIR/.zshenv) for
this kind of trick.
In zsh, any function name is allowed, even the empty
string, even those with spaces or NUL characters, using quoting:
$'\0' () echo I am the nul command
Or
'my command' () echo spaces in my name...
Forbidding functions (even importing them) with those names
doesn't bring any significant security benefit AFAICT.
>From what I understand, it was done as a simple fix to avoid
problems with env vars whose name contains shell code and
because bash parser does not support defining functions with
arbitrary names like zsh does.
A better fix, IMO, would have been to allow any name in a
function name, or allow the same names from imported functions
as for functions declared normally.
I'd agree that if you can no longer import them, not allowing
declaring them would make sense, but might break existing
scripts which rely on that ability.
Also, as I said before, what is deemed a valid identifier is
locale specific (and there's a bug in that it only works
properly in single-byte locales), so one can still make locales
where "("` or "=" are part of valid identifiers.
--
Stephane
Re: Bash-4.3 Official Patch 27
> I'd send it to your vendor. If appropriate they can send it upstream.
>
>
>
> Chet
I've sent this to a debian person following advice on the Arch list I initially
asked. I probably won't get used as I imagine they'll want a more general
approach to all the various versions of the bash fixes. Our ubuntu servers are
showing .025 right now and have environments with BASH_FUNC_()='()
{}' in them. Luckily I'm not using at on any of them and cron seems
unaffected.
Thanks for all the hard work on these panic issues.
Re: Bash-4.3 Official Patch 27
On 9/28/14, 12:10 PM, becker...@gmail.com wrote: > On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: > .. >> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch >> then I have a patch against the at(1) source which converts exported >> functions into something that sh can parse and allows exported functions to >> be used in the environment that calls at. >> > ... > > Jon Seymour asked me if my at patch would fix the following vulnerablity > (presumably in at(1)) > > echo pwd | env "/tmp/exploit=me" at tomorrow > > which I presume relies on acceptance of /tmp/exploit=me as a possible > command. I'm not sure it does since the current at code writes the variable > name out unconditionally (ie no inspection of characters etc etc). I could > probably raise an error for bad variable names, but I'm not sure I understand > what characters are now illegal or what the lexical definition of bash/sh > variable names is now. So I would appreciate advice on that. Variable names have the same grammar they always have: letters, digits, underscores, may not start with a digit. It's best to just ignore and pass along environment strings that you don't recognize. That's one of the goals of the changes in patch 27: to encode exported shell function names in a way that won't collide with valid shell variable names and assignment statements. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.3 Official Patch 27
� wrote: The change only affects environment variables **loaded as exported functions**. Bash won't forbid you from using / inside the name of an environment variables. The below doesn't demonstrate bash doing anything with the variable you declared. You declare an ENV var with 'env' (not part of bash), then you start a new shell and use env to see that the original value is still there. It should be. You are not demonstrating any interaction with BASH. You can easily confirm with: env -i 'foo/bar=baz' bash -c env Best regards Please fix your 'From' line. It shows up as garbage. Maybe it is your upstream ISP mailer.hiddenmail.het?
Re: Bash-4.3 Official Patch 27
On 9/28/14, 11:38 AM, becker...@gmail.com wrote: > If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch > then I have a patch against the at(1) source which converts exported > functions into something that sh can parse and allows exported functions to > be used in the environment that calls at. This looks like a problem with `at' assuming that everything in the environment is a valid shell assignment statement (or equivalent). Since the environment can include arbitrary strings, that's not a safe assumption. Bash, for instance, ignores and passes environment strings that it doesn't recognize as valid assignment statements. > Also is there anyone here who knows where such a patch should be sent? I'd send it to your vendor. If appropriate they can send it upstream. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.3 Official Patch 27
On 9/28/14, 12:48 AM, Eric Blake wrote:
> This patch forbids importing function names containing '/' (yay!), and
> we already established that bash has never been able to properly import
> functions with names containing '='. But I'm assuming there will need
> to be a followup patch to actually reject the attempt to create such
> function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
> issue an error message instead of printing "oops"), so that we do not
> have the confusing situation of being unable to pass all permitted
> function names through an export/import cycle.
I have not decided whether to reject the creation of such functions,
since bash never has, or to reject the attempt to export them.
That's a discussion that can be deferred.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.3 Official Patch 27
The change only affects environment variables **loaded as exported functions**. Bash won't forbid you from using / inside the name of an environment variables. You can easily confirm with: > env -i 'foo/bar=baz' bash -c env Best regards
Re: Bash-4.3 Official Patch 27
| correction: variable called "/tmp/exploit=me" => a variable called "/tmp/exploit" with a value "me" On Mon, Sep 29, 2014 at 2:26 AM, Jon Seymour wrote: > To clarify, I am not sure that the presence of a variable called > "/tmp/exploit=me" represents a huge vuilnerability for at(1) since > anyone who can arrange for this to happen can probably mutate the > user's environment in anyway they choose, but I did want to point out > that atrun will attempt to execute '/tmp/exploit=me' as a /bin/sh > command and should there be a executable file at that path, then an > unexpected execution may result. > > I note that my OSX environment currently contains this variable > injected by Chrome: > > COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket > > and attempts to invoke 'at' result in unexpected attempts to execute a > file called: > > COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket > > when 'atrun' runs. Of course, to exploit this, the attacker would have > to be able to create a file of that name on the filesystem and enable > 'atrun' (which is apparently disabled by default on OSX). > > > > On Mon, Sep 29, 2014 at 2:10 AM, wrote: >> On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: >> .. >>> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch >>> then I have a patch against the at(1) source which converts exported >>> functions into something that sh can parse and allows exported functions to >>> be used in the environment that calls at. >>> >> ... >> >> Jon Seymour asked me if my at patch would fix the following vulnerablity >> (presumably in at(1)) >> >> echo pwd | env "/tmp/exploit=me" at tomorrow >> >> which I presume relies on acceptance of /tmp/exploit=me as a possible >> command. I'm not sure it does since the current at code writes the variable >> name out unconditionally (ie no inspection of characters etc etc). I could >> probably raise an error for bad variable names, but I'm not sure I >> understand what characters are now illegal or what the lexical definition of >> bash/sh variable names is now. So I would appreciate advice on that.
Re: Bash-4.3 Official Patch 27
To clarify, I am not sure that the presence of a variable called "/tmp/exploit=me" represents a huge vuilnerability for at(1) since anyone who can arrange for this to happen can probably mutate the user's environment in anyway they choose, but I did want to point out that atrun will attempt to execute '/tmp/exploit=me' as a /bin/sh command and should there be a executable file at that path, then an unexpected execution may result. I note that my OSX environment currently contains this variable injected by Chrome: COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket and attempts to invoke 'at' result in unexpected attempts to execute a file called: COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket when 'atrun' runs. Of course, to exploit this, the attacker would have to be able to create a file of that name on the filesystem and enable 'atrun' (which is apparently disabled by default on OSX). On Mon, Sep 29, 2014 at 2:10 AM, wrote: > On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: > .. >> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch >> then I have a patch against the at(1) source which converts exported >> functions into something that sh can parse and allows exported functions to >> be used in the environment that calls at. >> > ... > > Jon Seymour asked me if my at patch would fix the following vulnerablity > (presumably in at(1)) > > echo pwd | env "/tmp/exploit=me" at tomorrow > > which I presume relies on acceptance of /tmp/exploit=me as a possible > command. I'm not sure it does since the current at code writes the variable > name out unconditionally (ie no inspection of characters etc etc). I could > probably raise an error for bad variable names, but I'm not sure I understand > what characters are now illegal or what the lexical definition of bash/sh > variable names is now. So I would appreciate advice on that.
Re: Bash-4.3 Official Patch 27
On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: .. > If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch > then I have a patch against the at(1) source which converts exported > functions into something that sh can parse and allows exported functions to > be used in the environment that calls at. > ... Jon Seymour asked me if my at patch would fix the following vulnerablity (presumably in at(1)) echo pwd | env "/tmp/exploit=me" at tomorrow which I presume relies on acceptance of /tmp/exploit=me as a possible command. I'm not sure it does since the current at code writes the variable name out unconditionally (ie no inspection of characters etc etc). I could probably raise an error for bad variable names, but I'm not sure I understand what characters are now illegal or what the lexical definition of bash/sh variable names is now. So I would appreciate advice on that.
Re: Bash-4.3 Official Patch 27
On Sunday, September 28, 2014 3:50:07 AM UTC+1, Chet Ramey wrote: > BASH PATCH REPORT > .. > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > >``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, ITS, CWRUc If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch then I have a patch against the at(1) source which converts exported functions into something that sh can parse and allows exported functions to be used in the environment that calls at. Looking at this list it's not clear to me if the dust has settled on the shellshock fixes. Should I wait before sharing my patch or not? Also is there anyone here who knows where such a patch should be sent?
Re: Bash-4.3 Official Patch 27
Does anyone know if Red Hat intends on remerging with official bash? (This
may be better directed at a seperate thread with them.)
-Nathan
On Sep 28, 2014 12:49 AM, "Eric Blake" wrote:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> >BASH PATCH REPORT
> >=
>
> > /* Don't import function names that are invalid identifiers from
> the
> >environment, though we still allow them to be defined as shell
> >variables. */
> > ! if (absolute_program (tname) == 0 && (posixly_correct == 0 ||
> legal_identifier (tname)))
> > ! parse_and_execute (temp_string, tname,
> SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
>
> This patch forbids importing function names containing '/' (yay!), and
> we already established that bash has never been able to properly import
> functions with names containing '='. But I'm assuming there will need
> to be a followup patch to actually reject the attempt to create such
> function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
> issue an error message instead of printing "oops"), so that we do not
> have the confusing situation of being unable to pass all permitted
> function names through an export/import cycle.
>
> By the way, thanks for this patch - it plugs CVE-2014-7186,
> CVE-2014-7187, and CVE-2014-6277 (and probably other parser crashes)
> from remote exploits down to merely annoying local bugs that can no
> longer be abused for privilege escalation. In other words, it is THIS
> patch that plugs the Shell Shock issue, even though there are still more
> patches needed to plug all of the parser holes that Shell Shock has
> uncovered.
>
> --
> Eric Blake eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
Re: Bash-4.3 Official Patch 27
On 09/27/2014 08:50 PM, Chet Ramey wrote:
>BASH PATCH REPORT
>=
> /* Don't import function names that are invalid identifiers from the
>environment, though we still allow them to be defined as shell
>variables. */
> ! if (absolute_program (tname) == 0 && (posixly_correct == 0 ||
> legal_identifier (tname)))
> ! parse_and_execute (temp_string, tname,
> SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
This patch forbids importing function names containing '/' (yay!), and
we already established that bash has never been able to properly import
functions with names containing '='. But I'm assuming there will need
to be a followup patch to actually reject the attempt to create such
function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
issue an error message instead of printing "oops"), so that we do not
have the confusing situation of being unable to pass all permitted
function names through an export/import cycle.
By the way, thanks for this patch - it plugs CVE-2014-7186,
CVE-2014-7187, and CVE-2014-6277 (and probably other parser crashes)
from remote exploits down to merely annoying local bugs that can no
longer be abused for privilege escalation. In other words, it is THIS
patch that plugs the Shell Shock issue, even though there are still more
patches needed to plug all of the parser holes that Shell Shock has
uncovered.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Bash-4.3 Official Patch 27
Chet Ramey wrote on Sat, 27 Sep 2014 22:50:07: > Bash-Release: 4.3 > Patch-ID: bash43-027 > Bug-Reported-by: Florian Weimer Excellent. Thanks for pulling in Florian Weimer's prefix/suffix approach. This is a big help. --- David A. Wheeler
