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

[Solar Designer <solar () openwall com>]

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