Tuesday, October 23, 2007

Spot the fed^H^H^Hbug

There is an interesting bug within wpa_supplicant's ASN.1 parsing. Usually, it uses the OpenSSL
libraray to obtain and parse the X509 certificates. However, it can be compiled to use built-in
X509 e.g. ASN.1 parsing routines to do so. Nearly all X509 functions use
asn1_get_next(). There is a buffer overflow condition within this function. Found it?
Make a comment!

P.S. Our packages do not use the vulnerable parsing code.

P.P.S. Puzzle-solving coming soon :-)


upb said...

assume buf = {0x1f, 0x00}
len = 2

6: pos = &buf[0]
7: end = &buf[2]

9: hdr->id = 0x1f, pos = &buf[1]
12: &buf[1] >= &buf[2] is false
17: tmp = 0x00, pos = &buf[2]
25: tmp = buf[2] <- out of bounds read

Icke said...

Indeed. But there is a more severe bug.

Anonymous said...

buf = { 0x1f, 0x80, < 0x80 }

Gives an "ASN.1: Length underflow", but reads buf[3] before ;)

Moritz Jodeit said...

Now that the check for the integer overflow has been removed from the screenshot ;P an integer overflow can be triggered with a buffer of {0x00,0x85,0xff,0xff,0xff,0xff,0xff}. This sets hdr->length to 0xffffffff and lets the last check for (pos + hdr->length > end) overflow, so that asn1_get_next() returns a asn1_hdr struct, with a really long hdr->length. If this length is used afterwards to write to hdr->payload, a simple buffer overflow happens.

Anonymous said...