Sorry! My conclusion (i.e. that RedHat was patched against this 3rd vulnerability) was just by running
env ls='() { echo vulnerable; }' bash -c ls
on my recently patched CentOS box. If I'm reading that right, if I was vulnerable, I'd get the output 'vulnerable'? But, instead, I got the correct output of the `ls` command.
The linked article was pertinent because RedHat did patch bash in a different way than upstream. Here's the relevant quote:
Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
And the post below which shows the contents of the RH patches should help, if I knew how to read it. :)
But... it seems to me that if this doesn't work:
env ls='() { echo vulnerable; }' bash -c ls
...then some scripts are now broken. Sorry, I don't know which ones. Needless to say, most bash scripts in existence don't take input from the wild wire. A sad day for those innocuous scripts.
Comments
If I'm looking at this correctly, it appears that the Red Hat patches aren't vulnerable to this particular vulnerability. (I believe they patched bash differently than upstream, as per https://securityblog.redhat.com/2014/09/26/frequently-asked-...)
EDIT: I tested on CentOS 6.5 and Fedora 18 (for which we'd manually backported the Fedora 19 patches).
I've read the page you linked and it's not clear to me how to reach that conclusion based on that information. Help?
Sorry! My conclusion (i.e. that RedHat was patched against this 3rd vulnerability) was just by running
env ls='() { echo vulnerable; }' bash -c ls
on my recently patched CentOS box. If I'm reading that right, if I was vulnerable, I'd get the output 'vulnerable'? But, instead, I got the correct output of the `ls` command.
The linked article was pertinent because RedHat did patch bash in a different way than upstream. Here's the relevant quote:
That help?
Yes, it helps, thanks!
And the post below which shows the contents of the RH patches should help, if I knew how to read it. :)
But... it seems to me that if this doesn't work:
...then some scripts are now broken. Sorry, I don't know which ones. Needless to say, most bash scripts in existence don't take input from the wild wire. A sad day for those innocuous scripts.mzs had some info about this in a separate comment[1] if you missed it. I've hit the edge of my knowledge about it. :-)
I don't use redhat, but my hunch is that the redhat patch is much more like Florian's (redhat security person):
http://seclists.org/oss-sec/2014/q3/693
Here is what has landed in Fedora, the fix is three patches:
http://pkgs.fedoraproject.org/cgit/bash.git/commit/?id=6319f...
If you're able to set arbitrary environment variables, then you could also emulate the prefix and suffix. e.g. this works even on patched F20:
But as others mention, this is not really a bash issue anymore, rather a general problem of sanitizing environments.Definitely works on Ubuntu and I'm assuming Debian as well.