5

I have two CentOS 5.10 boxen where I have upgraded bash to the latest version. However, in one of the boxes, bash is still vulnerable to CVE-2014-7169 (I am using the test from this ServerFault answer).

Any ideas on why one machine is OK and the other one isn't? What can I check for?

What I've checked already:

1- Ensure both machines are running the same OS (same output on both):

# cat /etc/redhat-release
CentOS release 5.10 (Final)

2- Ensure I have the same version of bash (same output on both):

# rpm -qi bash
Name        : bash                         Relocations: (not relocatable)
Version     : 3.2                               Vendor: CentOS
Release     : 33.el5_10.4                   Build Date: Thu 25 Sep 2014 08:58:19 PM UTC
Install Date: Sat 27 Sep 2014 02:07:07 PM UTC      Build Host: sclbuild-c5.centos.org
Group       : System Environment/Shells     Source RPM: bash-3.2-33.el5_10.4.src.rpm
Size        : 5235475                          License: GPLv2+
Signature   : DSA/SHA1, Fri 26 Sep 2014 02:11:39 AM UTC, Key ID a8a447dce8562897

3- Double check that the binary is OK signature wise (same output on both):

# rpm -V bash

(there was no output from this command, indicating the binary signatures checked out)

4- Check that the binaries are in fact the same versions (as suggested by Cyrus in the comments): (same output on both machines)

# rpm -qf /bin/bash
bash-3.2-33.el5_10.4

5- Check the size of the binaries

# ls -l /bin/bash    (Good machine)
-rwxr-xr-x 1 root root 801816 Sep 25 20:55 /bin/bash

# ls -l /bin/bash    (Bad/vulnerable machine)
-rwxr-xr-x 1 root root 768952 Sep 25 20:55 /bin/bash

Notice that the file sizes are different.

6- Actually test for the vulnerability

# ## on the good machine
# env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory

# ## on the bad/vulnerable machine
# env X='() { (a)=>\' sh -c "echo date"; cat echo
date
Sat Sep 27 13:44:36 UTC 2014
Community
  • 1
Oz Solomon
  • 375
  • 1
  • 3
  • 12
  • Hmm, on a recently updated i386 CentOS 5.10 box, I see the same package info as you, but my bash executable size is different from both of yours: `$ ls -l /bin/bash -rwxr-xr-x 1 root root 736348 Sep 25 17:03 /bin/bash` My bash is not vulnerable to 7169 after the update. – cjc Sep 27 '14 at 16:38
  • 1
    There are tests supplied by Red Hat - do they actually show your "bad" machine as vulnerable? Both tests are defined here: https://access.redhat.com/articles/1212303 – Joshua Miller Sep 27 '14 at 18:14
  • @cjc my box is 64-bit so the sizes will be different – Oz Solomon Sep 27 '14 at 18:44
  • @OzSolomon: `rpm -qf /bin/bash` Is the output the same? – Cyrus Sep 27 '14 at 20:15
  • @Cyrus - Both machines show the same result for -qf. I updated the question to reflect that. – Oz Solomon Sep 27 '14 at 20:33
  • @JoshuaMiller I can confirm that the second machine is vulnerable using RedHat's test. I'll update the question to show the actual result. – Oz Solomon Sep 27 '14 at 20:35
  • This doesn't explain why there's a problem, but for sanity, can you grab the RPM from, say, http://mirror.centos.org/centos/5/updates/x86_64/RPMS/ and force install using that? I would keep that vulnerable copy of /bin/bash around to do forensics later, if you feel like it. – cjc Sep 27 '14 at 22:13
  • Perhaps you've found another shell that is vulnerable, check what sh is linking to with `ls -l /bin/sh` . This is why I updated my answer on how to test, to specifically use bash. – BeowulfNode42 Sep 29 '14 at 03:23

1 Answers1

6

Could be a false positive - Make sure the 'echo' file does not exist from an earlier test on your bad machine, then retest.

Failing that, could also be a false negative - Check you can touch a file on your good machine, then retest.

aportr
  • 288
  • 3
  • 9
  • You nailed it! There was a file called 'echo' in the directory where I did the tests (probably from before upgrading). I deleted it and it worked fine. – Oz Solomon Sep 29 '14 at 15:53