Re: Environment variable of a name which is often used

[Eric Blake]

On 09/26/2014 11:31 AM, Norihiro Tanaka wrote:
> I tried 4.3.25 in order to check the details of CVE-2014-6271, and
> confirmed that the bug is fixed with a test case.
> 
> Next, I tried following case, and receive an output `rm -rf /'.  I seem
> that is designed, but it's also vulnerable.
> 
> $ cat <<EOF >test.sh
> #!/bin/bash
> cat /dev/null
> EOF
> 
> $ chmod a+x test.sh
> $ env cat='() { echo rm -rf /; }' ./test.sh
> 
> `cat' command is often used.  If we set write malicious code to
> environment variable named `cat', I see that it's often run, even if not
> expected.

This is a known issue, but NOT necessarily a security bug.  In other
words, it's no worse than running:

env LD_PRELOAD=... ./test.sh

with a malicious preload library.  Remember, the security aspect of
CVE-2014-6271 is that bash does unwanted parsing of the _contents_ of an
environment variable, and NOT that it is tied to the _name_ of the
variable.  The exploit happens because well-known programs stick
user-controlled contents into a name already under the program's
control, and NOT because well-known programs are creating arbitrary
names in the environment (that is, a vulnerable system running apache is
NOT creating arbitrary variables, so much as sticking arbitrary contents
into a variable named HTTP_...).

But, if that doesn't persuade you, then look at this patch that Red Hat
is using: http://www.openwall.com/lists/oss-security/2014/09/25/13

It has the benefit of exporting functions through a namespace that
CANNOT collide with a normal environment variable, and therefore, normal
environment variables CANNOT be used to call into the bash parser
without consent, avoiding all four of CVE-2014-6271, CVE-2014-7169,
CVE-2014-7186, CVE-2014-7187 in one patch.  Neat, huh?

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

signature.asc
Description: OpenPGP digital signature