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 :-)
Posts
4 comments:
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
Indeed. But there is a more severe bug.
buf = { 0x1f, 0x80, < 0x80 }
Gives an "ASN.1: Length underflow", but reads buf[3] before ;)
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.
Post a Comment