Older blog entries for argp (starting at number 39)

26 Apr 2010 (updated 22 Feb 2011 at 16:18 UTC) »

FreeBSD kernel exploitation mitigations

In my recent Black Hat Europe 2010 talk I gave an overview of the kernel exploitation prevention mechanisms that exist on FreeBSD. A few people at the conference have subsequently asked me to elaborate on the subject. In this post I will collect all the information from my talk and the various discussions I had in the Black Hat conference hallways.

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.


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)];
27:         arc4rand(guard, sizeof(guard), 0);
28:         for (i = 0; i 

During the protected function’s epilogue 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: {
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 an error occurs and the mapping fails. 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.


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 0x42 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 

This protection mechanism can obviously be easily bypassed.


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.

Syndicated 2010-04-26 10:38:23 (Updated 2011-02-22 17:55:00) from www.census-labs.com blog posts by author

Black Hat Europe 2010 update

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:

Syndicated 2010-04-22 08:39:53 (Updated 2010-04-22 08:39:45) from www.census-labs.com blog posts by author

Binding the Daemon - Black Hat Europe 2010

census 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!

Syndicated 2010-03-19 09:15:16 (Updated 2010-03-19 09:40:15) from www.census-labs.com blog posts by author


I have moved my blog to http://argp.gr/blog/. Please update your RSS reader's entry since I will no longer be directly updating my Advogato diary. The new feed is here.

exploit for CVE-2010-0453

While playing today with kmdb on OpenSolaris I wrote a denial of service (kernel panic) PoC exploit for the UCODE_GET_VERSION ioctl NULL pointer dereference vulnerability. The vulnerability was discovered by Tobias Klein who always publishes very detailed advisories:


You can get my exploit from:


first 2010 0day

md5: e8d5dd9d6cdf8602f12c8baef53f6550
sha1: 1322d45eed25260a0d5f85284011e1b205328807
sha256: eb4f95ec1b62d57e022c6945bdcb3f747f94f3ad7ddedc4bfde7dee23d4362ef

xmas 2009 0day

md5: a145ed9d7e1c33124daab40447cc5b56
sha1: c888985f209c26243206f8864783500b0c9353bb
sha256: 27cbcd01cf0e1b6a2ba82d4c0209a791957a3c1c29c131b0208f77981a1a81aa

14 Dec 2009 (updated 8 Mar 2010 at 17:09 UTC) »

Monkey HTTPd improper input validation vulnerability

census ID: census-2009-0004
Affected Products: Monkey web server versions ≤ 0.9.2.
Class: Improper Input Validation (CWE-20), Incorrect Calculation (CWE-682)
Remote: Yes
Discovered by: Patroklos Argyroudis

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.


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: char *Request_Find_Variable(char *request_body,  char *string)
365: {
366:   int pos_init_var=0, pos_end_var=0;
367:   char *var_value = 0;
369:   /* Existe *string en request_body ??? */        
370:   if (strstr2(request_body, string) == NULL)
371:       return NULL;
373:   pos_init_var = str_search(request_body, string, strlen(string));
374:   pos_end_var = str_search(request_body+pos_init_var, "\n", 1) — 1;
376:   if(pos_init_var

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: char *m_copy_string(const char *string, int pos_init, int pos_end)
424: {
425:   unsigned int size, bytes;
426:   char *buffer=0;
428:   size = (unsigned int) (pos_end — pos_init ) + 1;
429:   if(sizestrlen(string) || (pos_init > pos_end)){
438:       return NULL;
439:   }

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:   sr->connection = Request_Find_Variable(request_body, RH_CONNECTION);
345:   if((strstr2(sr->connection,"Keep-Alive"))!=NULL){
346:       sr->keep_alive=VAR_ON;
347:   }

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.

Syndicated 2009-12-14 12:04:04 (Updated 2010-03-08 18:27:38) from www.census-labs.com blog posts by author

3 Dec 2009 (updated 3 Dec 2009 at 19:57 UTC) »

Hellenic Air Force Academy free/open source event

census participated in the free/open source event held last month (Friday 23rd of October) at the Hellenic Air Force Academy (Σχολή Ικάρων).

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.

Syndicated 2009-12-03 11:00:45 (Updated 2009-12-03 11:00:48) from www.census-labs.com blog posts by author

CoreHTTP web server off-by-one buffer overflow vulnerability

census ID: census-2009-0003
CVE ID: CVE-2009-3586
Affected Products: CoreHTTP web server versions ≤
Class: Improper Input Validation (CWE-20), Failure to Constrain Operations within the Bounds of a Memory Buffer (CWE-119)
Remote: Yes
Discovered by: Patroklos Argyroudis

We have discovered a remotely exploitable “improper input validation” vulnerability in the CoreHTTP web server that leads to an off-by-one stack buffer overflow. The vulnerability can lead to denial of service attacks against the web server and potentially to the remote execution of arbitrary code with the privileges of the user running the server.


CoreHTTP is a minimalist web server focusing on speed and size. More information about its features can be found here.

CoreHTTP (up to and including version employs an insufficient input validation method for handling HTTP requests with invalid method names and URIs. Specifically, the vulnerability is an off-by-one buffer overflow in the sscanf() call at file src/http.c line numbers 45 and 46:

  45:    sscanf(parentsprock->buffer,
46:        "%" PATHSIZE_S "[A-Za-z] %" PATHSIZE_S "s%*[ \t\n]", req, url);

The buffers req and url are declared to be of size 256 bytes (PATHSIZE) and the sscanf() call writes 256 bytes (PATHSIZE_S) to these buffers without NULL terminating them.

Note that this is not vulnerability CVE-2007-4060 in which the same sscanf() call contained no bounds check at all.

This vulnerability can lead to denial of service attacks against the CoreHTTP web server and potentially to the remote execution of arbitrary code with the privileges of the user running the server. We have developed a proof-of-concept exploit to demonstrate the vulnerability.

To address the problem we propose the following unofficial patch (download it from here), since CoreHTTP’s author has not released an official fix yet:

  --- corehttp/src/common.h.orig  2009-12-01 09:29:18.000000000 +0200
+++ corehttp/src/common.h       2009-12-01 09:31:47.000000000 +0200
@@ -36,7 +36,7 @@
 #define BUFSIZE                2048
 #define BUFSIZE_S      "2048"
 #define PATHSIZE       256
-#define PATHSIZE_S     "256"
+#define PATHSIZE_S     "255"
 #define        SETSIZE         16


Syndicated 2009-12-02 09:47:13 (Updated 2009-12-02 18:31:43) from www.census-labs.com blog posts by author

30 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!