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

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54243BDC.30704@oracle.com>
Date: Thu, 25 Sep 2014 16:59:24 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com, chet.ramey@...e.edu
Subject: Re: CVE-2014-6271: remote code execution through bash

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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.