Re: CVE-2014-6271: remote code execution through bash

[John Haxby <john.haxby () oracle com>]

On 25/09/14 16:31, Simon McVittie wrote:
> The particularly nasty thing about CVE-2014-6271 is that the name of the
> variable is not relevant when exploiting that vulnerability, only the
> value, which means it will bypass many whitelists of safe variable
> names. I don't think that reduces the value of filtering
> attacker-supplied environments through a whitelist when not using a
> version of bash that is vulnerable.

(Added Chet back),

Indeed, and Michal Zalewski makes a similar point in
http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

I also said:
> I worry that simply fixing CVE-2014-6271 and CVE-2014-7129 is just
> setting the scene for the next parser problem.

Whitelisting won't protect you against the next parser bug and, anyway,
not everything has a blacklist, let alone a whitelist (su, I'm looking
at you).

I'm sure that there are going to be chains of exploits where each
program in the chain doesn't believe that it needs a whitelist.

For example, suid program A doesn't need a whitelist because it doesn't
go anywhere near a shell, the closest it gets is exec'ing one of a
well-defined set of programs ...

... one of which is written in python (say) and was recently modified to
exec a shell script for some perfectly innocent reason.

There are lots of things one could do to eliminate that risk, of course,
but step back and what are we arguing for?

I've seen several seasoned shell script writers, me included, who were
unaware of this feature in bash.   Both problems arose because of the
uncontrolled nature of function importing: you have no choice.

I /think/ Michal is arguing for making the import explicit.  I certainly am.

I'm equally certain Chet will do the right thing.

jch