4 ms·
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 recen
by dahjelle 12y ago
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.
That help?
- daveloyall 12y agoYes, 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: 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.
- dahjelle 12y agomzs had some info about this in a separate comment[1] if you missed it. I've hit the edge of my knowledge about it. :-)
- mzs 12y agoI 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 http://seclists.org/oss-sec/2014/q3/693
- verbatim 12y agoHere is what has landed in Fedora, the fix is three patches: http://pkgs.fedoraproject.org/cgit/bash.git/commit/?id=6319f7c362cfe http://pkgs.fedoraproject.org/cgit/bash.git/commit/?id=6319f...