[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVE-2014-7187

From: Eric Blake
Subject: Re: CVE-2014-7187
Date: Fri, 10 Oct 2014 08:41:05 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

On 10/10/2014 08:00 AM, Nabiałek, Wojciech wrote:

> This code is not mine, refer to: 
> http://stevejenkins.com/blog/2014/09/how-to-manually-update-bash-to-patch-shellshock-bug-on-older-fedora-based-systems/
>  Exploit 5. 

That blog is wrong.  Here's how you test if your shell is vulnerable:

probe='() { echo vulnerable; }' bash -c probe

If that outputs:

bash: probe: command not found

your shell is secure (and bash 4.3.30 has this behavior).  If it outputs:


then your shell still needs a patch.  Remember, bash 4.3.27 was THE
patch that matters.  There were six patches in a row, five of them (25,
26, 28, 29, and 30) addressed 6 different parser bugs (all 6 of which
were assigned a CVE number), but none of those five solve the
vulnerability.  ONLY patch 27 (the one with no corresponding CVE)
actually solves the vulnerability.  The vulnerability was that attackers
could abuse the contents of environment variables to cause the parser to
be executed when it should not be.

Some of the sites purporting to have tests for the various
vulnerabilities are confusing the two issues - there's a difference
between a parser bug (and we've patched 6 of them so far) and an
exploitable vulnerability (a single patch solved that, AND prevents even
yet-to-be-discovered parser bugs from also being vulnerabilities).  In
particular, the code you quoted did not have ANY mention of an
environment variable; therefore, it CANNOT be testing the vulnerability,
only whether a parser bug is present.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]