We have discovered two improper input validation vulnerabilities in the FreeBSD kernel’s NFS client-side implementation (FreeBSD 8.0-RELEASE, 7.3-RELEASE and 7.2-RELEASE) that allow local unprivileged users to escalate their privileges, or to crash the system by performing a denial of service attack.

Details

FreeBSD is an advanced operating system which focuses on reliability and performance. More information about its features can be found here.

FreeBSD 8.0-RELEASE, 7.3-RELEASE and 7.2-RELEASE employ an improper input validation method in the kernel’s NFS client-side implementation. Specifically, the first vulnerability is in function nfs_mount() (file src/sys/nfsclient/nfs_vfsops.c) which is reachable from the mount(2) and nmount(2) system calls. In order for them to be enabled for unprivileged users the sysctl(8) variable vfs.usermount must be set to a non-zero value.

The function nfs_mount() employs an insufficient input validation method for copying data passed in a structure of type nfs_args from userspace to kernel. Specifically, the file handle buffer to be mounted (args.fh) and its size (args.fhsize) are completely user-controllable. The unbounded copy operation is in file src/sys/nfsclient/nfs_vfsops.c (the excerpts are from 8.0-RELEASE):

1094
1095
1096
1097
1098
1099

if (!has_fh_opt) {
      error = copyin((caddr_t)args.fh, (caddr_t)nfh,
           args.fhsize);
    if (error) {
         goto out;
      }

The declaration of the variables args and nfh is at:

786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820

static int
nfs_mount(struct mount *mp)
{
        struct nfs_args args = {
            .version = NFS_ARGSVERSION,
            .addr = NULL,
            .addrlen = sizeof (struct sockaddr_in),
            .sotype = SOCK_STREAM,
            .proto = 0,
            .fh = NULL,
            .fhsize = 0,
            .flags = NFSMNT_RESVPORT,
            .wsize = NFS_WSIZE,
            .rsize = NFS_RSIZE,
            .readdirsize = NFS_READDIRSIZE,
            .timeo = 10,
            .retrans = NFS_RETRANS,
            .maxgrouplist = NFS_MAXGRPS,
            .readahead = NFS_DEFRAHEAD,
            .wcommitsize = 0,                   /* was: NQ_DEFLEASE */
            .deadthresh = NFS_MAXDEADTHRESH,    /* was: NQ_DEADTHRESH */
            .hostname = NULL,
            /* args version 4 */
            .acregmin = NFS_MINATTRTIMO,
            .acregmax = NFS_MAXATTRTIMO,
            .acdirmin = NFS_MINDIRATTRTIMO,
            .acdirmax = NFS_MAXDIRATTRTIMO,
        };
        int error, ret, has_nfs_args_opt;
        int has_addr_opt, has_fh_opt, has_hostname_opt;
        struct sockaddr *nam;
        struct vnode *vp;
        char hst[MNAMELEN];
        size_t len;
        u_char nfh[NFSX_V3FHMAX];

This vulnerability can cause a kernel stack overflow which leads to privilege escalation on FreeBSD 7.3-RELEASE and 7.2-RELEASE. On FreeBSD 8.0-RELEASE the result is a kernel crash/denial of service due to the SSP/ProPolice kernel stack-smashing protection which is enabled by default. Versions 7.1-RELEASE and earlier do not appear to be vulnerable since the bug was introduced in 7.2-RELEASE. In order to demonstrate the impact of the vulnerability we have developed a proof-of-concept privilege escalation exploit. A sample run of the exploit follows:

[argp@julius ~]$ uname -rsi
FreeBSD 7.3-RELEASE GENERIC
[argp@julius ~]$ sysctl vfs.usermount
vfs.usermount: 1
[argp@julius ~]$ id
uid=1001(argp) gid=1001(argp) groups=1001(argp)
[argp@julius ~]$ gcc -Wall nfs_mount_ex.c -o nfs_mount_ex
[argp@julius ~]$ ./nfs_mount_ex
[*] calling nmount()
[!] nmount error: -1030740736
nmount: Unknown error: -1030740736
[argp@julius ~]$ id
uid=0(root) gid=0(wheel) egid=1001(argp) groups=1001(argp)

The second vulnerability exists in the function mountnfs() that is called from function nfs_mount():

1119
1120

error = mountnfs(&args, mp, nam, args.hostname, &vp,
    curthread->td_ucred);

The function mountnfs() is reachable from the mount(2) and nmount(2) system calls by unprivileged users. As with the nfs_mount() case above, this requires the sysctl(8) variable vfs.usermount to be set to a non-zero value.

The file handle to be mounted (argp->fh) and its size (argp->fhsize) are passed to function mountnfs() from function nfs_mount() and are user-controllable. These are subsequently used in an unbounded bcopy() call (file src/sys/nfsclient/nfs_vfsops.c):

1219

bcopy((caddr_t)argp->fh, (caddr_t)nmp->nm_fh, argp->fhsize);

The above can cause a kernel heap overflow when argp->fh is bigger than 128 bytes (the size of nmp->nm_fh) since nmp is an allocated item on the Universal Memory Allocator (UMA, the FreeBSD kernel’s heap allocator) zone nfsmount_zone (again from src/sys/nfsclient/nfs_vfsops.c):

1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175

static int
mountnfs(struct nfs_args *argp, struct mount *mp, struct sockaddr *nam,
    char *hst, struct vnode **vpp, struct ucred *cred)
{
        struct nfsmount *nmp;
        struct nfsnode *np;
        int error;
        struct vattr attrs;
 
        if (mp->mnt_flag & MNT_UPDATE) {
                nmp = VFSTONFS(mp);
                printf("%s: MNT_UPDATE is no longer handled here\n", __func__);
                free(nam, M_SONAME);
                return (0);
        } else {
                nmp = uma_zalloc(nfsmount_zone, M_WAITOK);

This kernel heap overflow can lead on FreeBSD 8.0-RELEASE, 7.3-RELEASE and 7.2-RELEASE to privilege escalation and/or a kernel crash/denial of service attack. Similarly to the first vulnerability, FreeBSD 7.1-RELEASE and earlier versions do not appear to be vulnerable. We have developed a proof-of-concept DoS exploit to demonstrate the vulnerability. Furthermore, we have also developed a privilege escalation exploit for this second vulnerability which will not be released at this point.

FreeBSD has released an official advisory and a patch to address both vulnerabilities. All affected parties are advised to follow the upgrade instructions included in the advisory and patch their systems.

Userland memory corruption protections (also known as exploitation mitigations) have made most of the generic exploitation approaches obsolete. This is true both on Windows and Unix-like operating systems. In order to successfully achieve arbitrary code execution from a vulnerable application nowadays a researcher needs to look to the memory layout and the code structure of the particular application.

On the other hand, exploitation mitigation mechanisms for kernel code have not seen the same level of adoption mostly due to the performance penalty they introduce. This has increased the interest in viewing the operating system kernel as part of the attack surface targeted in a penetration test. Therefore, many operating systems have started to introduce kernel exploitation mitigations. The recent CanSecWest talk by Tavis Ormandy and Julien Tinnes titled “There’s a party at Ring0, and you’re invited” presented an overview of such mitigations on Windows and Linux.

FreeBSD also has a number of memory corruption protections for kernel code. Not all of these were developed with the goal of undermining attacks, but primarily as debugging mechanisms. Some are enabled by default in the latest stable version (8.0-RELEASE) and some are not.

Stack-smashing

Kernel stack-smashing protection for FreeBSD was introduced in version 8.0 via ProPolice/SSP. Specifically, the file src/sys/kern/stack_protector.c is compiled with gcc’s -fstack-protector option and registers an event handler called __stack_chk_init 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. Below is the relevant part of the stack_protector.c file:

10: __stack_chk_guard[8] = {};
    ...
20: #define __arraycount(__x)       (sizeof(__x) / sizeof(__x[0]))
21: static void
22: __stack_chk_init(void *dummy __unused)
23: {
24:         size_t i;
25:         long guard[__arraycount(__stack_chk_guard)];
26: 
27:         arc4rand(guard, sizeof(guard), 0);
28:         for (i = 0; i < __arraycount(guard); i++)
29:                 __stack_chk_guard[i] = guard[i];
30: }

When the protected 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 (again from the stack_protector.c file):

13: void
14: __stack_chk_fail(void)
15: {
16: 
17:         panic("stack overflow detected; backtrace may be corrupted");
18: }

ProPolice/SSP also performs local variable and pointer reordering in order to protect against the corruption of variables and pointers due to stack buffer overflow vulnerabilities.

NULL page mappings

Also in version 8.0, FreeBSD has introduced a protection against user mappings at address 0 (NULL). This exploitation mitigation mechanism is exposed through the sysctl(8) variable security.bsd.map_at_zero and is enabled by default (i.e. the variable has the value 0). When a user request is made for the NULL page and the feature is enabled, the kernel instead of returning address 0 it returns address 0×1000. Obviously this protection is ineffective in vulnerabilities which the attacker can (directly or indirectly) control the kernel dereference offset. For an applicable example see the exploit for vulnerability CVE-2008-3531 I have previously published.

Heap-smashing

FreeBSD has introduced kernel heap-smashing detection in 8.0-RELEASE via an implementation
called RedZone. RedZone is oriented more towards debugging the kernel memory allocator rather than detecting and stopping deliberate attacks against it. If enabled (it is disabled by default) RedZone places a static canary value of 16 bytes above and below each buffer allocated on the heap. The canary value consists of the hexadecimal value 0×42 repeated in these 16 bytes.

During a heap buffer’s deallocation the canary value is checked and if it has been corrupted the details of the corruption (address of the offending buffer and stack traces of the buffer’s allocation and deallocation) are logged. The code that performs the check for a heap overflow is the following (from file src/sys/vm/redzone.c):

166: ncorruptions = 0;
167: for (i = 0; i < REDZONE_CFSIZE; i++, faddr++) {
168:       if (*(u_char *)faddr != 0x42)
169:               ncorruptions++;
170: }

This protection mechanism can obviously be easily bypassed.

Use-after-free

MemGuard is a replacement kernel memory allocator introduced in FreeBSD version 6.0 and is designed to detect use-after-free bugs in kernel code. Similarly to RedZone, MemGuard mainly targets debugging scenarios and does not constitute a mechanism to mitigate deliberate attacks. However, MemGuard is not compatible and cannot replace the Universal Memory Allocator’s (UMA – which is the default kernel allocator in FreeBSD) calls. Therefore (and also due to the overhead it introduced even before UMA was developed), it is not enabled by default.

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

• To enable kmdb edit the kernel’s grub entry and append -k to it.
• Break into kmdb: f1+a
• Display status: ::status
• List available kmdb commands (and be amazed): ::dcmds
• View registers for CPU 0: ::cpuregs -c 0 and/or ::regs
• Set a breakpoint at the given symbol or address: ::bp [symbol or address]
• Set a read/write watchpoint at the given symbol or address: [symbol or address] ::wp -rw
• Display breakpoints and watchpoints: ::events
• Delete breakpoint (or watchpoint) #1: ::delete 1
• Continue execution: :c
• Next instruction, step into function calls: ::step
• Next instruction, step over function calls: ::step over
• Return from current function: ::step out
• Continue execution until the next branching instruction (only x86): ::step branch
• Disassemble around RIP: <rip::dis
• Disassemble 100 instructions starting at the given symbol or address: ::dis -n 100 [symbol or address]
• View backtrace: $C
• View IDT: ::idt
• View symbols: ::nm
• View the kernel message buffer: ::msgbuf
• Quit kmdb and reboot: ::quit

This brief cheatsheet does not do kmdb justice; it is an amazing built-in kernel debugger with countless features. For more details read the manpage.

http://www.trapkit.de/advisories/TKADV2010-001.txt

You can get my exploit from:

http://census-labs.com/media/cve-2010-0453.c

We have discovered a remotely exploitable “improper input validation” vulnerability in the Monkey web server that allows an attacker to perform denial of service attacks by repeatedly crashing worker threads that process HTTP requests.

Details

Monkey is a fast, efficient, small and easy to configure HTTP/1.1 compliant web server. It has been designed to be scalable with low memory and CPU consumption. More information about its features can be found here.

Monkey (up to and including version 0.9.2) employs an insufficient input validation method for handling HTTP requests with invalid connection headers. Specifically, the vulnerability is in the calculation for the end of the request body buffer related to newline characters in function Request_Find_Variable() in the file src/request.c:

364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386

char *Request_Find_Variable(char *request_body,  char *string)
{
   int pos_init_var=0, pos_end_var=0;
   char *var_value = 0;
 
   /* Existe *string en request_body ??? */        
   if (strstr2(request_body, string) == NULL)
       return NULL;
 
   pos_init_var = str_search(request_body, string, strlen(string));
   pos_end_var = str_search(request_body+pos_init_var, "\n", 1) - 1;
 
   if(pos_init_var<=0 || pos_end_var<=0){
       return  NULL;   
   }
 
   pos_init_var += strlen(string) + 1;
   pos_end_var = (unsigned int) (pos_init_var  + pos_end_var) - (strlen(string) +1);
 
   var_value = m_copy_string(request_body, pos_init_var, pos_end_var);
 
   return (char *) var_value;
}

With a specially crafted request body the pos_init_var integer can take the value 0x1c (28 in decimal) and the pos_end_var integer can take the value 0x1a (26 in decimal). Then in the m_copy_string() function, the calculation for the unsigned integer size in line 428 (file src/utils.c) leads to a signedness bug and m_copy_string() returns NULL (line 438, file src/utils.c):

423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439

char *m_copy_string(const char *string, int pos_init, int pos_end)
{
   unsigned int size, bytes;
   char *buffer=0;
 
   size = (unsigned int) (pos_end — pos_init ) + 1;
   if(size<=2) size=4;
 
   buffer = M_malloc(size);
 
   if(!buffer){
       return NULL;
   }
 
   if(pos_end>strlen(string) || (pos_init > pos_end)){
       return NULL;
   }

This causes Request_Find_Variable() to return NULL (line 344, file src/request.c) and this to be used in the strstr2() call at line 345 of file src/request.c:

344
345
346
347

sr->connection = Request_Find_Variable(request_body, RH_CONNECTION);
if((strstr2(sr->connection,"Keep-Alive"))!=NULL){
    sr->keep_alive=VAR_ON;
}

This vulnerability can allow an attacker to perform denial of service attacks by repeatedly crashing Monkey worker threads that process HTTP requests. We have developed a proof-of-concept exploit to demonstrate the vulnerability.

The maintainer of Monkey has been contacted and a new version of the web server (0.9.3) has been released that addresses this issue. All affected parties are advised to upgrade to the latest version available.

Our talk presented an overview of the available free/open source software that can be used to build complete security solutions for public offices and infrastructure. Furthermore, we analysed recorded cyberwarfare incidents and how the open source model can aid in establishing robust defenses. The slides from our presentation are available here (in Greek).

We would like to cordially thank Professor Antonios Andreatos for inviting us to the event and for his organisational efforts.