Re: Issue with Bash-4.3 Official Patch 27
No, I can't. $ foo%%=bar foo%%=bar: command not found Or better said not in the normal way $ set foo%%=bar -- Mit freundlichen Grüßen Lorenz Bucher TechConnect GmbH Im Auftrag der/on behalf of Rohde Schwarz GmbH Co. KG Postfach 80 14 69 • 81614 München Mühldorfstraße 15 • 81671 München Telefon:(089) 4129-15684 Mail: lorenz.bucher@rohde-schwarz.com Internet: www.rohde-schwarz.com Von:Chet Ramey chet.ra...@case.edu An: lorenz.bucher@rohde-schwarz.com, wool...@eeg.ccf.org, Kopie: bug-bash@gnu.org, Eduardo A. Bustamante López dual...@gmail.com, chet.ra...@case.edu Datum: 10/16/2014 03:09 PM Betreff:Re: Issue with Bash-4.3 Official Patch 27 Gesendet von: bug-bash-bounces+lorenz.bucher.ext=rohde-schwarz@gnu.org On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: But anyway. In my opinion I should trust a shell not violating their own rules and be able to import their own variables. That's not the issue. The shell can import variables like that just fine, as evidenced by exported functions actually working. The question is whether or not `export' lets you set and export non-identifiers. It does and should not. So the % character should be allowed to be used in variable names. No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: Issue with Bash-4.3 Official Patch 27
On 10/16/14, 4:37 PM, Geir Hauge wrote: Regardless though, shouldn't source (declare -xp) work whether or not the environment contains invalid identifiers? It doesn't at present: $ env %=% bash -c 'echo $BASH_VERSION; source (declare -xp)' 4.3.30(1)-release /dev/fd/63: line 1: declare: `%': not a valid identifier Isn't declare -p output meant to be reusable as shell input? Yeah. Names that get imported from the environment, but which are not valid shell identifiers, should not leak into declare -p output. I made that change about ten days ago, and it will be in the next release of bash. The current warning is an annoyance but otherwise doesn't impact anything. 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: Issue with Bash-4.3 Official Patch 27
On 10/17/14, 11:22 AM, lorenz.bucher@rohde-schwarz.com wrote: No, I can't. $ foo%%=bar foo%%=bar: command not found You just demonstrated what I wrote: No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. You attempted to create a shell variable with a name that isn't a valid shell identifier, and it didn't work. You can use `env' or equivalent to place arbitrary strings into the environment, but you can't use the shell to do it. 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: Issue with Bash-4.3 Official Patch 27
On 10/17/14, 11:34 AM, Greg Wooledge wrote: 3) Everything else. These are ignored. Not quite. Bash saves them and adds them to the environment it passes to the external commands it invokes. Bash is transparent with respect to environment variables it doesn't handle. 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: Issue with Bash-4.3 Official Patch 27
On 10/15/14, 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote: Hello, in refer to http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables with suffix %% can't be set/exported. This makes problems restoring environments which where saved by external programs like printenv (see example below) This trick -- which was always fragile because printenv is not a robust way to do this -- will not work any more. One of the reasons we implemented the new exported function name encoding scheme was to avoid name collisions with exported variables. You can use `export -f' to generate a function definition and declaration that you can save in a file for later use. 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: Issue with Bash-4.3 Official Patch 27
On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: But anyway. In my opinion I should trust a shell not violating their own rules and be able to import their own variables. That's not the issue. The shell can import variables like that just fine, as evidenced by exported functions actually working. The question is whether or not `export' lets you set and export non-identifiers. It does and should not. So the % character should be allowed to be used in variable names. No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. -- ``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/
Issue with Bash-4.3 Official Patch 27
Hello,
in refer to
http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
with suffix %% can't be set/exported.
This makes problems restoring environments which where saved by external
programs like printenv (see example below)
I saw this issue on Ubuntu 12.04 with
bash version GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
examples:
$ foo() { echo bar; }
$ export -f foo
$ echo export BASH_FUNC_foo%%='$(printenv BASH_FUNC_foo%%)' | tee ./env
export BASH_FUNC_foo%%='() { echo bar
}'
$ source ./env
bash: export: `BASH_FUNC_foo%%=() { echo bar
}': not a valid identifier
$ export BASH_FUNC_foo%%='() { echo bar; }'
bash: export: `BASH_FUNC_foo%%=() { echo bar; }': not a valid
identifier
$ export BASH_FUNC_foo='() { echo bar; }'
bucher_l@zim:/vobs/1GP1AdminVob/Tools/ldapadmin$ echo $BASH_FUNC_foo
() { echo bar; }
Re: Issue with Bash-4.3 Official Patch 27
On Wed, Oct 15, 2014 at 08:50:25AM -0700, Eduardo A. Bustamante López wrote: On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com wrote: variables with suffix %% can't be set/exported. This makes problems restoring environments which where saved by external programs like printenv (see example below) I'm not sure if this is a bug, because I doubt that function exporting was intended to use that way. Just source a file with the function definitions... My take was that he's got some script that does an environment save/restore and the function exports broke it. He may not especially care about restoring the functions, as long as they don't get in the way of the real variables. That said, his save/restore technique is going to break on *any* environment variable that isn't a valid shell variable name, which includes a much larger set of things than just BASH_FUNC_foo%%. He simply hasn't encountered any of these other things yet (and may never encounter them in real life, depending on his environment).
Re: Issue with Bash-4.3 Official Patch 27
On Oct 15, 2014, at 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote:
Hello,
in refer to
http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
with suffix %% can't be set/exported.
This makes problems restoring environments which where saved by external
programs like printenv (see example below)
I saw this issue on Ubuntu 12.04 with
bash version GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
examples:
$ foo() { echo bar; }
$ export -f foo
$ echo export BASH_FUNC_foo%%='$(printenv BASH_FUNC_foo%%)' | tee ./env
export BASH_FUNC_foo%%='() { echo bar
}'
$ source ./env
bash: export: `BASH_FUNC_foo%%=() { echo bar
}': not a valid identifier
$ export BASH_FUNC_foo%%='() { echo bar; }'
bash: export: `BASH_FUNC_foo%%=() { echo bar; }': not a valid
identifier
Given the changes made for shellshock, I doubt the above will ever work again.
Try
env | sed 's/^BASH_FUNC_\([^%]*\)%%=/\1/'
or
echo export BASH_FUNC_foo%%='$(printenv BASH_FUNC_foo%%)' | sed
's/^BASH_FUNC_\([^%]*\)%%=/\1/' | tee ./env
to strip function descriptors.
Re: Issue with Bash-4.3 Official Patch 27
Yes, you got it. I just gave an example to reproduce that Bug. In my case I didn't find the save script/binary yet. I use unset -f function as workaround. But anyway. In my opinion I should trust a shell not violating their own rules and be able to import their own variables. So the % character should be allowed to be used in variable names. Von:Greg Wooledge wool...@eeg.ccf.org An: Eduardo A. Bustamante López dual...@gmail.com, Kopie: lorenz.bucher@rohde-schwarz.com, bug-bash@gnu.org Datum: 10/15/2014 05:58 PM Betreff:Re: Issue with Bash-4.3 Official Patch 27 On Wed, Oct 15, 2014 at 08:50:25AM -0700, Eduardo A. Bustamante López wrote: On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com wrote: variables with suffix %% can't be set/exported. This makes problems restoring environments which where saved by external programs like printenv (see example below) I'm not sure if this is a bug, because I doubt that function exporting was intended to use that way. Just source a file with the function definitions... My take was that he's got some script that does an environment save/restore and the function exports broke it. He may not especially care about restoring the functions, as long as they don't get in the way of the real variables. That said, his save/restore technique is going to break on *any* environment variable that isn't a valid shell variable name, which includes a much larger set of things than just BASH_FUNC_foo%%. He simply hasn't encountered any of these other things yet (and may never encounter them in real life, depending on his environment).
Re: Issue with Bash-4.3 Official Patch 27
On 10/15/2014 11:49 AM, lorenz.bucher@rohde-schwarz.com wrote: Yes, you got it. I just gave an example to reproduce that Bug. In my case I didn't find the save script/binary yet. I use unset -f function as workaround. But anyway. In my opinion I should trust a shell not violating their own rules and be able to import their own variables. So the % character should be allowed to be used in variable names. No, it should not. POSIX is already explicit that applications MUST be prepared to tolerate garbage in the environment (by ignoring or purging names that they don't like): http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html These strings have the form name=value; names shall not contain the character '='. For values to be portable across systems conforming to POSIX.1-2008, the value shall be composed of characters from the portable character set (except NUL and as indicated below). There is no meaning associated with the order of strings in the environment. If more than one string in an environment of a process has the same name, the consequences are undefined. Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the underscore ( '_' ) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. That said, one of the proposals on this list is to add a _single_ new environment variable, maybe named BASH_FUNC_EXPORTS, that contains a list of all exported functions (and maybe even a sanity check prefix stating how many functions are in the list, to make parsing a little more robust), so that people can easily whitelist or blacklist a single environment variable name/value pair to cover all functions, and so that bash is no longer sticking non-portable names in the environment. By having a SINGLE known-special variable, we still avoid the Shellshock vulnerability (the problem there was that the namespace that triggered special handling was infinite, and therefore caused collisions with regular variables and difficulty in blacklisting when sanitizing across a security boundary). -- 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
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_name()='()
{}' 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
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
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
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 ebl...@redhat.com 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 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
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, 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.
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 jon.seym...@gmail.com 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, 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.
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
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
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
� 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, 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/
Bash-4.3 Official Patch 27
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-027
Bug-Reported-by:Florian Weimer fwei...@redhat.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported functions to avoid
clashes with shell variables and to avoid depending only on an environment
variable's contents to determine whether or not to interpret it as a shell
function.
Patch (apply with `patch -p0'):
*** ../bash-4.3.26/variables.c 2014-09-25 23:02:18.0 -0400
--- variables.c 2014-09-27 20:52:04.0 -0400
***
*** 84,87
--- 84,92
#define ifsname(s)((s)[0] == 'I' (s)[1] == 'F' (s)[2] == 'S'
(s)[3] == '\0')
+ #define BASHFUNC_PREFIX BASH_FUNC_
+ #define BASHFUNC_PREFLEN 10 /* == strlen(BASHFUNC_PREFIX */
+ #define BASHFUNC_SUFFIX %%
+ #define BASHFUNC_SUFFLEN 2 /* == strlen(BASHFUNC_SUFFIX) */
+
extern char **environ;
***
*** 280,284
static void dispose_temporary_env __P((sh_free_func_t *));
! static inline char *mk_env_string __P((const char *, const char *));
static char **make_env_array_from_var_list __P((SHELL_VAR **));
static char **make_var_export_array __P((VAR_CONTEXT *));
--- 285,289
static void dispose_temporary_env __P((sh_free_func_t *));
! static inline char *mk_env_string __P((const char *, const char *, int));
static char **make_env_array_from_var_list __P((SHELL_VAR **));
static char **make_var_export_array __P((VAR_CONTEXT *));
***
*** 350,369
/* If exported function, define it now. Don't import functions from
the environment in privileged mode. */
! if (privmode == 0 read_but_dont_execute == 0 STREQN (() {,
string, 4))
{
string_length = strlen (string);
! temp_string = (char *)xmalloc (3 + string_length + char_index);
! strcpy (temp_string, name);
! temp_string[char_index] = ' ';
! strcpy (temp_string + char_index + 1, string);
/* Don't import function names that are invalid identifiers from the
environment, though we still allow them to be defined as shell
variables. */
! if (legal_identifier (name))
! parse_and_execute (temp_string, name,
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
! if (temp_var = find_function (name))
{
VSETATTR (temp_var, (att_exported|att_imported));
--- 355,385
/* If exported function, define it now. Don't import functions from
the environment in privileged mode. */
! if (privmode == 0 read_but_dont_execute == 0
! STREQN (BASHFUNC_PREFIX, name, BASHFUNC_PREFLEN)
! STREQ (BASHFUNC_SUFFIX, name + char_index - BASHFUNC_SUFFLEN)
! STREQN (() {, string, 4))
{
+ size_t namelen;
+ char *tname; /* desired imported function name */
+
+ namelen = char_index - BASHFUNC_PREFLEN - BASHFUNC_SUFFLEN;
+
+ tname = name + BASHFUNC_PREFLEN; /* start of func name */
+ tname[namelen] = '\0';/* now tname == func name */
+
string_length = strlen (string);
! temp_string = (char *)xmalloc (namelen + string_length + 2);
! memcpy (temp_string, tname, namelen);
! temp_string[namelen] = ' ';
! memcpy (temp_string + namelen + 1, string, string_length + 1);
/* 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);
! if (temp_var = find_function (tname))
{
VSETATTR (temp_var, (att_exported|att_imported));
***
*** 378,383
}
last_command_exit_value = 1;
! report_error (_(error importing function definition for `%s'),
name);
}
}
#if defined (ARRAY_VARS)
--- 394,402
}
last_command_exit_value = 1;
! report_error (_(error importing function definition for `%s'),
tname);
}
+
+ /* Restore original suffix */
+ tname[namelen] = BASHFUNC_SUFFIX[0];
}
#if defined (ARRAY_VARS)
***
*** 2955,2959
INVALIDATE_EXPORTSTR (var);
! var-exportstr = mk_env_string (name, value);
array_needs_making = 1;
--- 2974,2978
INVALIDATE_EXPORTSTR (var);
! var-exportstr = mk_env_string (name, value, 0);
array_needs_making = 1;
***
*** 3853,3871
static inline char *
!
Re: Bash-4.3 Official Patch 27
Chet Ramey chet.ra...@case.edu wrote on Sat, 27 Sep 2014 22:50:07: Bash-Release: 4.3 Patch-ID: bash43-027 Bug-Reported-by: Florian Weimer fwei...@redhat.com Excellent. Thanks for pulling in Florian Weimer's prefix/suffix approach. This is a big help. --- David A. Wheeler
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
