Executable Hijinks

Posted on by December 30, 2012

In prepping some RHEL 5.5 laptops, I noticed something odd. Very odd. I had made some changes to a base system and did an rsync -av -n from the base system to a pristine source installation to see what had changed. I was expecting to see differences configuration files in /etc, /root, perhaps /var. Nothing prepared me for this:

# ls -al base/bin/bash pristine-source/bin/bash
-rwxr-xr-x 1 root root 801512 Oct 21  2008 base/bin/bash
-rwxr-xr-x 1 root root 768664 Oct 21  2008 pristine-source/bin/bash

Whoa! My base system’s bash shell increased in size. When this happens, it is paramount to determine why. The repercussions are significant.

The first place to look is to see if what RPM installs the executable.

# chroot /mnt/pristine-source rpm -q -f /bin/bash
bash-3.2-24.el5
# chroot /mnt/base rpm -q -f /bin/bash
bash-3.2-24.el5

Strike one. I should probably post the md5sums here:

# md5sum /mnt/pristine-source/bin/bash /mnt/base/bin/bash
dbb9e394d5e2017fb460c4f7d8618f59  /mnt/pristine-source/bin/bash
ecb556dec39092617bbbe8fbef06e381  /mnt/base/bin/bash

Perhaps there is a different RPM installed?

# chroot /mnt/base rpm -q -a > /tmp/base.rpms
# chroot /mnt/pristine-source rpm -q -a > /tmp/pristine-source.rpms
# diff /tmp/pristine-source.rpms /tmp/base.rpms
#

Strike two. I just queried both installations, and they have the exact same RPMs installed. Taking a look at shared libraries required to run bash:

# ldd -v /mnt/pristine-source/bin/bash /mnt/base/bin/bash
/mnt/pristine-source/bin/bash:
	libtermcap.so.2 => /lib64/libtermcap.so.2 (0x00002b0e241c1000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00002b0e243c4000)
	libc.so.6 => /lib64/libc.so.6 (0x00002b0e245c8000)
	/lib64/ld-linux-x86-64.so.2 (0x00002b0e23fa4000)

	Version information:
	/mnt/pristine-source/bin/bash:
		libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
		libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
	/lib64/libtermcap.so.2:
		libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
	/lib64/libdl.so.2:
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
		libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
	/lib64/libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
/mnt/base/bin/bash:
	libtermcap.so.2 => /lib64/libtermcap.so.2 (0x00002ab1f0ec8000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00002ab1f10cb000)
	libc.so.6 => /lib64/libc.so.6 (0x00002ab1f12cf000)
	/lib64/ld-linux-x86-64.so.2 (0x00002ab1f0cab000)

	Version information:
	/mnt/base/bin/bash:
		libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
		libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
	/lib64/libtermcap.so.2:
		libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
	/lib64/libdl.so.2:
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
		libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
	/lib64/libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

I am picking on bash, but you’ll see how systemic this problem is:

ls -alL /mnt/pristine-source/lib/libc.so.6 /mnt/base/lib/libc.so.6 
-rwxr-xr-x 1 root root 1611564 Mar 10  2010 /mnt/base/lib/libc.so.6
-rwxr-xr-x 1 root root 1608148 Mar 10  2010 /mnt/pristine-source/lib/libc.so.6

Right. Strike 3. All programs use the shared C library.

Here is the bash file, stored with xz and base64. This format prevents accidentally running the suspect shell.

Comments are closed.