undefined | Better HN

0 pointsdahjelle11y ago0 comments

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?

0 comments

4 comments · 2 top-level

daveloyall11y ago· 1 in thread

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:

    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.

dahjelleOP11y ago

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. :-)

mzs11y ago· 1 in thread

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

verbatim11y ago

Here is what has landed in Fedora, the fix is three patches:

http://pkgs.fedoraproject.org/cgit/bash.git/commit/?id=6319f...

j / k navigate · click thread line to collapse