Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014

[Eric Blake]

On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote:
> Is the response (workarounds and patch) being discussed elsewhere ?
> 
> 
> (1) Patch
> 
> Looking at the code, it seems that the problem is that in
>  initialize_shell_variables(), when an inheritable function is detected in
> the environment by the "() {" prefix, we then directly
> call parse_and_execute(), on the whole string.
> Obviously this includes any trailing commands after "} ;". A proper fix
> would need to tweak the parser to do a parse_and_execute_one_command().
> Anybody already working along those lines ?

Official patches have already been released to stop parsing too far
(CVE-2014-6271), additional patches will be posted soon for the fact
that errors in the parser can still be exploited (CVE-2014-7169).
http://www.openwall.com/lists/oss-security/2014/09/ is discussing some
of the further patches that have already been proposed, to make sure
that we don't have yet a third round of updates required.

> 
> (2) Workaround
> 
> Privileged mode skips the import of functions from the environment, hence
> "#! /bin/bash -p" is a quick fix.
> I assume that 99.9% of uses would be unaffected by the other side-effects
> of -p.
> Am I missing something ?

Yes.  Among others, system(3) and popen(3) call /bin/sh, if /bin/sh is
bash, there is no way for you to pass -p into that child.  The set of
programs that set environment variables to user-controlled contents and
then fork a child process that may or may not use bash is shockingly
high.  Patching bash is much easier than trying to chase down every
invocation of bash to change those invocations to add -p.

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
is also a good read, as well as the archives of this list.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature