[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140925160532.GA869@openwall.com>
Date: Thu, 25 Sep 2014 20:05:33 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: chet.ramey@...e.edu
Subject: Re: CVE-2014-6271: remote code execution through bash
On Thu, Sep 25, 2014 at 04:17:31PM +0100, John Haxby wrote:
> There seems to be a wider issue even when we have well-formed functions
> coming in, for example,
>
> env rm='() { echo will not; }' bash -c 'rm core'
John first brought this aspect up on the private distros list, but I
asked for it to be moved to oss-security, which John did (thanks!)
My reply on distros was:
| It appears that right now we're only dealing with the case when the
| attacker can't specify arbitrary env var names. Attacks are limited in
| that way if performed e.g. via/on sshd forced command or httpd CGI
| interface.
|
| With an arbitrary env var, you could arguably do lots of damage anyway -
| e.g., via LD_PRELOAD. However, I think there are notable exceptions to
| this - e.g., when a sudo-like program or/and libc resets the known
| variables like LD_*, but does not use a whitelist, so things like a
| variable named "rm" (or BASH_FUNC_rm() after Florian's patch) would
| make it through a SUID exec, switching of privs to another user, and
| exec'ing a script. So, yes, there may be an issue here for some setups
| that are risky but are not necessarily exploitable otherwise.
|
| I don't know if there's any plan to deal with this issue. We really
| ought to discuss it on oss-security.
> My feeling is that if you're going to import functions from the
> environment then you should do that explicitly either through a switch
> (--import?) or a builtin that can import all or selected functions. Or
> both.
While your specific examples are not necessarily relevant, I agree that
in the long run the functionality should be restricted in a way like you
suggest.
> I worry that simply fixing CVE-2014-6271 and CVE-2014-7129 is just
> setting the scene for the next parser problem.
That's my feeling too.
At the very least, we also need Florian's patch adding a prefix and a
suffix to the variable names, although this won't be sufficient against
local attacks via existing blacklist-using sudo-like wrappers.
Our excuse is that blacklists are not a good practice anyway.
Alexander
Powered by blists - more mailing lists
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.
