oss-sec mailing list archives
Re: CVE-2014-6271: remote code execution through bash
From: Solar Designer <solar () openwall com>
Date: Thu, 25 Sep 2014 20:05:33 +0400
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
Current thread:
- Re: CVE-2014-6271: remote code execution through bash, (continued)
- Re: CVE-2014-6271: remote code execution through bash Huzaifa Sidhpurwala (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Huzaifa Sidhpurwala (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash John Haxby (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Michal Zalewski (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Simon McVittie (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash John Haxby (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Simon McVittie (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Simon McVittie (Sep 26)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Message not available
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Alexandre Dulaunoy (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Larry W. Cashdollar (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Dwayne Litzenberger (Sep 26)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 26)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 26)