oss-sec mailing list archives
Re: Healing the bash fork
From: "David A. Wheeler" <dwheeler () dwheeler com>
Date: Mon, 29 Sep 2014 14:50:07 -0400 (EDT)
On Sep 29, 2014, at 11:59 AM, Eric Blake <eblake () redhat com> wrote:But I see no reason to move away from %% suffixing.
On 29 September 2014 10:39, Kobrin, Eric <ekobrin () akamai com> wrote:
The suffix fixes the obvious CGI hole, but it leaves exposed programs in which the adversary gets to choose the variable name as well...
On Mon, 29 Sep 2014 10:49:22 -0700, Tavis Ormandy <taviso () cmpxchg8b com> wrote:
If an adversary can choose the variable name, it's game over by definition. He can choose LD_PRELOAD, SHELLOPTS='xtrace' PS4='$(foo)', ...
I agree. If an adversary can arbitrary control the environment, it is definitely game over. What's more, this has been true for decades and this is *clearly* documented all over the place. If some program allows an untrusted user to control the content in arbitrary environment variables, that would be a security vulnerability in that other program, not in bash.
This general solution is robust, now we're just hammering out the details.
I agree, Florian Weimer's approach does a *great* job of completely countering the general attack path as currently understood. I also like Chet Ramey's tweak that changes the suffix from "()" to "%%", that's a nice refinement (the suffix no longer contains metacharacters). That said, a lot of people are looking to find other attack paths. Shellshock has pointed out a kind of attack path that most people hadn't examined before. I'd still like to see Christos Zoulas's approach included eventually, since that's an even stronger countermeasure. After all, if function imports only happen on request, then non-requesters will have no problem. But I also understand that Zoulas's approach is backwards-incompatible, and thus the bash folks are hesitant to apply it. If that can't be added now, perhaps it could be added in a next release of bash? --- David A. Wheeler
Current thread:
- Re: CVE-2014-6271: remote code execution through bash, (continued)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash Hanno Böck (Sep 27)
- Re: CVE-2014-6271: remote code execution through bash Eric Blake (Sep 28)
- Healing the bash fork (was: Re: [oss-security] CVE-2014-6271: remote code execution through bash) Florian Weimer (Sep 29)
- Re: Healing the bash fork Eric Blake (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Tavis Ormandy (Sep 29)
- Re: Healing the bash fork David A. Wheeler (Sep 29)
- Re: Healing the bash fork John Haxby (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Chet Ramey (Sep 29)
- Re: Healing the bash fork gremlin (Sep 29)
- Re: Healing the bash fork Florian Weimer (Sep 30)
- Re: Healing the bash fork Gennady Kupava (Sep 30)
- Re: Healing the bash fork gremlin (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Michal Zalewski (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)