argp's blog

Black Hat Europe 2010 is now over and after a brief ash cloud caused delay I am back in Greece. It has been a great conference, flawlessly organised and with many outstanding presentations. I would like to thank everyone that attended my presentation but also all the kind people that spoke to me before and afterwards. I hope to meet all of you again at a future event.

My presentation, titled “Binding the Daemon: FreeBSD Kernel Stack and Heap Exploitation”, was divided into four parts. In the first part I gave an overview of the published work on the subject of kernel exploitation for Unix-like operating systems. The second and third parts were the main body of the presentation. Specifically, in the second part I explained how a kernel stack overflow vulnerability on FreeBSD can be leveraged to achieve arbitrary code execution. The third part focused on a detailed security analysis of the Universal Memory Allocator (UMA), the FreeBSD kernel’s memory allocator. I explored how UMA overflows can lead to arbitrary code execution in the context of the latest stable FreeBSD kernel (8.0-RELEASE), and I developed an exploitation methodology for privilege escalation and kernel continuation.

In the fourth and final part I gave a demo of a FreeBSD kernel local 0day vulnerability that I have discovered. However, I have not released the details of the vulnerability in my Black Hat presentation. The details of this vulnerability (plus the proof-of-concept exploit) will be released shortly, once the relevant code is patched and the official advisory is out.

Below you may find all the material of my presentation, updated with some extra information and minor corrections:

• Slides: bheu-2010-slides.pdf
• White paper: bheu-2010-wp.pdf
• Source code: bheu-2010-src.tar.gz

Census, Inc will be presenting “Binding the Daemon”, an in-depth analysis of FreeBSD kernel stack and kernel heap exploitation methodologies at Black Hat Europe 2010. This year the European Black Hat Briefings conference will be held in Barcelona, Spain. We hope to see you there!

Last May (2008/05/30) I presented my research on FreeBSD kernel stack overflows at the University of Piraeus Software Libre Society, Event #16: Computer Security. The slides from my talk are now available from the research section of the census web page.

In the talk I explored in detail the process of exploiting kernel stack overflows in the 7.0 production release of the FreeBSD operating system. There were extensive examples and live experimentation, all of which are unfortunately not reflected in the supporting slides. The main contribution of the study is the development of a kernel exploitation algorithm and the presentation of comprehensive i386 kernel shellcode. Although the focus was on the then most current production release of FreeBSD (7.0), the presented algorithm and methodologies are applicable to both the latest stable (7.1) and current (8.0) FreeBSD versions.

The FreeBSD kernel can be debugged with the ddb(4) interactive kernel debugger. Although the latest production release of FreeBSD (7.1 at the time of this writing) adds some very useful features, ddb is still lacking the flexibility of gdb.

The FreeBSD developer’s handbook has a section on kernel debugging using remote gdb, but it is not directly applicable to VMware-based installations. The solution is to use VMware’s feature of creating virtual serial ports as named pipes to emulate a serial connection between two FreeBSD virtual machines.

The first FreeBSD virtual machine, let’s call it the target host to follow the handbook’s terminology, is the machine that the experimental kernel code runs on. The second, the debugging host, is the one that will run gdb and connect over the virtual serial connection to the target host. The target host’s kernel needs to be compiled with the following options:

makeoptions DEBUG=-g
options GDB
options DDB
options KDB

Furthermore, the serial port needs to be defined in the device flags in the /boot/device.hints file of the target host by setting the 0x80 bit, and the 0x10 bit for specifying that the kernel gdb backend is to be accessed via remote debugging over this port:

hint.sio.0.flags="0x90"

Also, edit the target host’s /etc/sysctl.conf file to include the following self-explanatory kernel parameters:

debug.kdb.current=ddb
debug.debugger_on_panic=1

After the compilation and installation of the new kernel on the target host, the /usr/obj/usr/src/sys/TARGET_HOST directory (assuming you have named the new kernel TARGET_HOST) needs to be copied to the debugging host (for example with scp -r).

For the following steps both virtual machines need to be turned off. In VMware go to the tab of the target host, click Edit virtual machine settings->Add->Serial Port->Output to named pipe. Enter /tmp/com_1 (or whatever you want) as the named pipe, select This end is the server and The other end is a virtual machine. Then perform the same steps on the debugging host’s virtual machine, enter the same named pipe, but select This end is the client in this case. The /tmp/com_1 named pipe on the machine that runs VMware (Linux in our case) will be used as a virtual serial connection between the two FreeBSD guests.

Now power on the target host normally, cause a kernel panic or start the kernel debugger manually, and type gdb and then s:

[root@target_host]# sysctl debug.kdb.enter=1
KDB: enter: sysctl debug.kdb.enter
[thread pid 578 tid 100063 ]
Stopped at kdb_enter+0x2b: nop
db> gdb
Step to enter the remote GDB backend.
db> s

On the debugging host you need to find the device that corresponds to the virtual serial port you defined in VMware. On our setup it is /dev/cuad0. Then start a kgdb remote debugging session in the /usr/obj/usr/src/sys/TARGET_HOST directory, passing as arguments the serial port device and the kernel to be debugged:

[root@debugging_host ~]# cd /usr/obj/usr/src/sys/TARGET_HOST
[root@debugging_host /usr/obj/usr/src/sys/TARGET_HOST]# kgdb -r /dev/cuad0 \
  ./kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Switching to remote protocol
kdb_enter (msg=0x23 <Address 0x23 out of bounds>) at
 /usr/src/sys/kern/subr_kdb.c:270
270 }
 
Unread portion of the kernel message buffer:
KDB: enter: sysctl debug.kdb.enter
 
#0  kdb_enter (msg=0x23 <Address 0x23 out of bounds>) at
 /usr/src/sys/kern/subr_kdb.c:270
270 }
(kgdb) bt
#0  kdb_enter (msg=0x23 <Address 0x23 out of bounds>) at
 /usr/src/sys/kern/subr_kdb.c:270
#1  0xc0657710 in kdb_sysctl_enter (oidp=0xc08d3fa0, arg1=0x0, arg2=0,
 req=0xcca54c04) at /usr/src/sys/kern/subr_kdb.c:175
#2  0xc0646f2b in sysctl_root (oidp=0x0, arg1=0x0, arg2=0, req=0xcca54c04) at
 /usr/src/sys/kern/kern_sysctl.c:1248
#3  0xc0647128 in userland_sysctl (td=0x23, name=0xcca54c74, namelen=3,
 old=0xcca54c04, oldlenp=0x0, inkernel=0, new=0xbfbfe428, newlen=35,
 retval=0xcca54c70, flags=35) at /usr/src/sys/kern/kern_sysctl.c:1347
#4  0xc0646fcb in __sysctl (td=0xc164d180, uap=0xcca54d04) at
 /usr/src/sys/kern/kern_sysctl.c:1282
#5  0xc0811dcf in syscall (frame=
 {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 3, tf_esi = 0,
 tf_ebp = -1077943368, tf_isp = -861581980, tf_ebx = 672367844,
 tf_edx = 0, tf_ecx = -1077941184, tf_eax = 202, tf_trapno = 12,
 tf_err = 2, tf_eip = 671840819, tf_cs = 51, tf_eflags = 658,
 tf_esp = -1077943428, tf_ss = 59}) at
 /usr/src/sys/i386/i386/trap.c:976
#6  0xc08007bf in Xint0x80_syscall () at
 /usr/src/sys/i386/i386/exception.s:200
#7  0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)

That’s it. Now let’s do some debugging.

The new Phrack issue is out at last!

My contribution to Phrack issue #66 is an article on exploiting FreeBSD’s kernel memory allocator, or UMA – the universal memory allocator. The initial inspiration to work on this subject came to me from signedness.org challenge #3 by karl, therefore I felt it was the right thing to do to add karl as a co-author.

Issue #66 contains in total three articles by Greek authors, Exploiting DLmalloc frees in 2009 by huku and Exploiting TCP Persist Timer Infiniteness by ithilgore in addition to mine. And that’s just amazing!

Stack-smashing detection and protection for the kernel has been enabled by default in the latest snapshot of FreeBSD 8.0-CURRENT (200811). This was accomplished by utilizing the incorporation of SSP (also known as ProPolice) in gcc version 4.1 and later (the 200811 snapshot uses gcc 4.2.1).

Specifically, src/sys/kern/stack_protector.c, which is compiled with gcc’s -fstack-protector option, registers an event handler that generates a random canary value (the “guard” variable in SSP terminology) placed between the local variables and the saved frame pointer of a kernel process’s stack during a function’s prologue. When the function exits, the canary is checked against its original value. If it has been altered the kernel calls panic(9) bringing down the whole system, but also stopping any execution flow redirection caused by manipulation of the function’s saved frame pointer or saved return address.

In contrast to StackGuard and StackShield (or even Microsoft’s /GS), SSP has been effective against attacks aiming to directly bypass it. This relates to research I have done in the near past on the subject of kernel stack-smashing attacks. However, SSP can be indirectly bypassed by several methods, for example heap overflows, integer and/or signedness vulnerabilities, and stack overflows on buffers smaller than 8 bytes, among others.