5 ms·

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 different

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-questions-about-the-shellshock-bash-flaws/. 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).

daveloyall 12y ago
I've read the page you linked and it's not clear to me how to reach that conclusion based on that information. Help?
- 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 ago
    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.
    - dahjelle 12y 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. :-)
  - mzs 12y ago
    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 http://seclists.org/oss-sec/2014/q3/693
    - verbatim 12y ago
      Here 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...
drzaiusapelord 12y ago
Definitely works on Ubuntu and I'm assuming Debian as well.
CUViper 12y ago
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: $ env 'BASH_FUNC_ls()=() { echo myls; }' bash -c ls myls But as others mention, this is not really a bash issue anymore, rather a general problem of sanitizing environments.

daveloyall 12y ago

I've read the page you linked and it's not clear to me how to reach that conclusion based on that information. Help?

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 ago
  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.
  - dahjelle 12y 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. :-)
- mzs 12y ago
  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 http://seclists.org/oss-sec/2014/q3/693
  - verbatim 12y ago
    Here 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...

drzaiusapelord 12y ago

Definitely works on Ubuntu and I'm assuming Debian as well.

CUViper 12y ago

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: $ env 'BASH_FUNC_ls()=() { echo myls; }' bash -c ls myls But as others mention, this is not really a bash issue anymore, rather a general problem of sanitizing environments.