CERT/NIST reveal level 10 bash alert today, 24 September 2014
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 ?
(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 ?
-Alex
Detecting invocation as /bin/sh ?
Hello, In the wake of the exported func bug, as can be seen in the nearby thread "Issues with exported functions", many people are just now discovering a host of things that bash does, of course in a documented way, but that they never needed in the first place. Of course, their intention is precisely expressed by the '#!/bin/sh' header in scripts, but most major Unices today just have a symbolic link there (sh->bash). So, what about, in bash's initialization, detecting that we are invoked as "/bin/sh", and disabling all those bells and whistles (or behaving as bash -p, which is a close approximation) ? Note we already have something similar with the name "rbash" that triggers restricted mode: restricted_shell = shell_is_restricted (shell_name); So I'm merely proposing to do the same with privileged_mode (or a close cousin if its side effects are too strong): privileged_mode = shell_is_legacy_sh (shell_name); Reactions ? -Alex
Re: Detecting invocation as /bin/sh ?
On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
> Alexandre Ferrieux writes:
>
> > So, what about, in bash's initialization, detecting that we are invoked as
> > "/bin/sh",
>
> It already does. See (bash) Bash POSIX Mode.
Yes, it does do this detection, but too late for our concern, since things
occur in the following order:
(1) set_shell_name(argv[0]) => this detects "sh" and sets 'act_like_sh'
(2) shell_initialize() => this decides to import funcs from env depending on
flags like 'posixly_correct'
(3) if (act_like_sh) ... sv_strict_posix ("POSIXLY_CORRECT")
So it seems the order is wrong. As a consequence, and this is confirmed by
experience, the #!/bin/sh prefix behaves as featuristic bash.
My suggestion then is to undo that mistake.
-Alex
Re: Detecting invocation as /bin/sh ?
On Friday, September 26, 2014 2:14:46 PM UTC+2, Greg Wooledge wrote: > On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote: > > > Of course, their intention is precisely expressed by the '#!/bin/sh' header > > Unfortunately, most people don't actually express an intent when they > use #!/bin/sh. They just copy some code from a random script they found > somewhere, without understanding what it means. That song reminds me of PHP. I was under the optimistic assumption that bash, given its noble ancestry, was not exactly targeting the same audience. > The number of scripts that use #!/bin/sh but then go on to use Bash > syntax is higher than you might believe. OK. Sh*t happens. Bozos write scripts. So what ? A more interesting question IMO is: How many packaged init scripts / mission-critical daemons are written by people that cannot be bothered to write #! /bin/bash when they require bash ? > It's not a stretch of the imagination to suppose that someone has used > exported functions in a #!/bin/sh script on a Linux box where /bin/sh > is a symlink to bash. Except that script would instantly break if *dash* was installed, instead of bash, as target of the sh symlink. So that beast would already be extremely fragile. -Alex
Re: Issues with exported functions
On Saturday, September 27, 2014 8:19:49 AM UTC+2, Eric Blake wrote: > > I am also in favor of both approaches - moving shell functions into a > non-colliding namespace (so that arbitrary contents of regular variables > CANNOT trigger parser bugs) and making shell function exports > configurable and off by default. On that second point: an even lower-hanging fruit is "off by default when invoked as sh". Regardless of bash's evolution, let's stop jeopardizing the very life of the overwhelming mass of #!/bin/sh scripts. Please. -Alex PS: Dunno whether CGI will ever recover from this week's blow. The sh-bash confusion is the real murderer of that innocent victim.
Re: Detecting invocation as /bin/sh ?
On Monday, September 29, 2014 9:51:45 PM UTC+2, Chet Ramey wrote: > > > > So it seems the order is wrong. As a consequence, and this is confirmed by > > experience, the #!/bin/sh prefix behaves as featuristic bash. > > My suggestion then is to undo that mistake. > > Posix mode was never intended to turn bash into a shell that provides only > what Posix specifies and nothing more. It makes bash conform to Posix by > changing things where the default mode differs from what Posix specifies. > Posix allows this, and allows extensions, and every shell that claims > Posix conformance (except perhaps `posh') offers extensions beyond minimal > Posix features. Forget about posix mode then: bash -p (privileged) offers a lean-and-mean variant which pretty much satisfies anybody needing "just sh". However, there is no way to store an option in a symbolic link, so all distributions doing "sh -> bash" are bound to perpetuate the danger (of "eval-from-the-env"). So it would seem normal for some of them to move away from bash as the default sh. -Alex
Re: Detecting invocation as /bin/sh ?
On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote:
>
> > Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
> > variant which pretty much satisfies anybody needing "just sh". However,
> > there is no way to store an option in a symbolic link, so all distributions
> > doing "sh -> bash" are bound to perpetuate the danger (of
> > "eval-from-the-env"). So it would seem normal for some of them to move away
> > from bash as the default sh.
>
> Are we talking about the same thing?
> Privileged mode is intended for use when bash might run setuid (a bad idea
> in any case). It affects what bash will use from the environment -- yes,
> including shell functions -- and inhibits setting the euid to the ruid.
> It doesn't have any other effect. It certainly doesn't turn off any bash
> features.
It *does* disable that embarrassing nightmare of a misfeature that is function
import:
if (privmode == 0 && ... && STREQN ("() {", string, 4))
...
parse_and_execute(...)
So, from the perspective of a "just the sh, Ma'am" goal, it is a pretty good
contender. Regardless of the faith one can have in the recent patches, shunning
that 'parse_and_execute(environment)' altogether sounds orders of magnitude
safer.
-Alex
Re: Detecting invocation as /bin/sh ?
On Tuesday, September 30, 2014 2:42:33 AM UTC+2, Chet Ramey wrote: > On 9/29/14, 7:53 PM, Alexandre Ferrieux wrote: > > > > [bash -p] *does* disable that embarrassing nightmare of a misfeature that > > is function import: > > I guess if that's what you mean by "just the sh", then yes, it does. > That's a unique interpretation. You may deem this a peculiar interpretation, but it might be shared by the overwhelming crowd of those who never noticed (before last week) 1/ that bash was "powering" their decades-old init scripts and CGIs and 2/ that bash evalled something from the env. The consequence of all this might well be a switch. -Alex
Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014
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
Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)
On 26/09/2014 08:23, Ralf Naegele wrote:
Hello Eduardo,
I haven't installed the patched bash yet. I called it in the source
directory after compiling, it with ./bash so I think this should start the
patched bash.
You started ./bash as the parent reading the offending line, but did you also
modify it so that ./bash appears inside ?
env x='() { :;}; echo vulnerable' ./bash -c "echo this is a test"
This is important since the bug occurs in the child, at init time (within
shell_initialize_variables)
-Alex
