bug-bash
[Top][All Lists]
Advanced

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

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


From: Alexandre FERRIEUX - SOFT/LAN
Subject: Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014
Date: Thu, 25 Sep 2014 23:42:12 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0

On 25/09/2014 22:51, Eric Blake wrote:
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.

Thanks. Like thousands of people I guess, I have never imagined before today that a "bash bug" could exist, so I'm new to this list, and did not realized its archive was lagging a bit. Sorry about re-asking.


(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.
Argh indeed.

Out of curiosity, may I ask what purpose 'export -f' serves ? In 20+ years of unix (admittedly sticking to /bin/sh for lack of a compelling need of anything else), I have never felt the need to share function across a fork/exec (across a fork, of course, in subshells; but not a fork/exec). So what is that use-case that motivated that tricky feature ?

-Alex



reply via email to

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