Advogato blog for argp

21 Feb 2010

Sun, 21 Feb 2010 17:53:22 GMT

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.

7 Feb 2010

Sun, 7 Feb 2010 17:48:04 GMT

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:

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

You can get my exploit from:

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

6 Jan 2010

Wed, 6 Jan 2010 15:52:02 GMT

first 2010 0day

md5: e8d5dd9d6cdf8602f12c8baef53f6550
sha1: 1322d45eed25260a0d5f85284011e1b205328807
sha256: eb4f95ec1b62d57e022c6945bdcb3f747f94f3ad7ddedc4bfde7dee23d4362ef

24 Dec 2009

Thu, 24 Dec 2009 15:04:46 GMT

xmas 2009 0day

md5: a145ed9d7e1c33124daab40447cc5b56
sha1: c888985f209c26243206f8864783500b0c9353bb
sha256: 27cbcd01cf0e1b6a2ba82d4c0209a791957a3c1c29c131b0208f77981a1a81aa

Monkey HTTPd improper input validation vulnerability

Mon, 14 Dec 2009 11:19:19 GMT

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.

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: 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;
368:
369:   /* Existe *string en request_body ??? */        
370:   if (strstr2(request_body, string) == NULL)
371:       return NULL;
372:
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;
375:
376:   if(pos_init_var<=0 || pos_end_var<=0){
377:       return  NULL;   
378:   }
379:
380:   pos_init_var += strlen(string) + 1;
381:   pos_end_var = (unsigned int) (pos_init_var  + pos_end_var)
                                — (strlen(string) +1);
382:
383:   var_value = m_copy_string(request_body, pos_init_var, pos_end_var);
384:
385:   return (char *) var_value;
386: }

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;
427:
428:   size = (unsigned int) (pos_end — pos_init ) + 1;
429:   if(size<=2) size=4;
430:
431:   buffer = M_malloc(size);
432:
433:   if(!buffer){
434:       return NULL;
435:   }
436:
437:   if(pos_end>strlen(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.

Hellenic Air Force Academy free/open source event

Thu, 3 Dec 2009 09:12:29 GMT

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.

CoreHTTP web server off-by-one buffer overflow vulnerability

Wed, 2 Dec 2009 17:11:10 GMT

census ID:	census-2009-0003
CVE ID:	CVE-2009-3586
Affected Products:	CoreHTTP web server versions ≤ 0.5.3.1.
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.

Details

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 0.5.3.1) 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

 #ifndef GLOBALS_DEFINED

Linux kernel SUNRPC off-by-two buffer overflow

Tue, 1 Dec 2009 21:12:42 GMT

census ID:	census-2009-0005
Affected Products:	Linux kernel versions from 2.6.32 to 2.6.32-rc7.
Class:	Off-by-two stack buffer overflow.
Discovered by:	Patroklos Argyroudis

We have found an off-by-two stack buffer overflow in the Linux kernel SUNRPC implementation. Linux kernel versions from 2.6.32 to 2.6.32-rc7 are affected.

Details

There is an off-by-two stack buffer overflow in function rpc_uaddr2sockaddr() of file net/sunrpc/addr.c in the Linux kernel SUNRPC implementation. It was introduced in commit a02d692611348f11ee1bc37431a883c3ff2de23e.

The function rpc_uaddr2sockaddr() that is used to convert a universal address to a socket address takes as an argument the size_t variable uaddr_len (the length of the universal address string). The stack buffer buf is declared in line 315 to be of size RPCBIND_MAXUADDRLEN. If the passed argument uaddr_len is equal to RPCBIND_MAXUADDRLEN then the condition of line 319 is false and then at lines 324 and 325 there are two out-of-bounds assignments:

312: size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
313:                           struct sockaddr *sap, const size_t salen)
314: {
315:        char *c, buf[RPCBIND_MAXUADDRLEN];
            ...
319:        if (uaddr_len > sizeof(buf))
320:            return 0;
            ...
324:        buf[uaddr_len] = '\n';
325:        buf[uaddr_len + 1] = '\0';
            ...
363: }
364: EXPORT_SYMBOL_GPL(rpc_uaddr2sockaddr);

Since the function rpc_uaddr2sockaddr() is declared as an EXPORT_SYMBOL_GPL function it can be used by kernel modules and potentially be reachable by user input. The bug was reported and fixed in 2.6.32-rc8 (commit 1e360a60b24ad8f8685af66fa6de10ce46693a4b).

26 Aug 2009

Wed, 26 Aug 2009 20:00:57 GMT

flickr is the new bugtraq

I decided to start disclosing bugs on flickr.

ld-linuxv.so.1 rootkit

Fri, 21 Aug 2009 13:14:40 GMT

Yesterday I helped my friend kargig to analyse a rootkit he has recovered from a compromised Linux system. You can find the complete write-up at his blog.