Stack buffer overflow in WolfSSL before 3.13.0
During some tests of TLS libraries I found a stack buffer overflow vulnerability in the WolfSSL library.
Finding this one was surprisingly simple: I had a wolfssl server that was compiled with address sanitizer and ran the SSL Labs test against it.
The bug happens in the parsing of the signature hash algorithm list that is sent in a ClientHello and is basically a textbook stack buffer overflow. WolfSSL simply tries to store that in an array with 32 elements. If one sends more than 32 hash algorithms it overflows.
With the SSL Labs scan the bug only causes WolfSSL to terminate if it's compiled with address sanitizer, but if one sends a very large list of hash algorithms it also crashes in a normal compile. In situations where WolfSSL is used without ASLR this bug is probably trivially exploitable.
I have created a simple bash proof of concept (using netcat and xxd) that crashes a WolfSSL server.
The bug was fixed in this commit and in version 3.13.0 of WolfSSL.
Finding this one was surprisingly simple: I had a wolfssl server that was compiled with address sanitizer and ran the SSL Labs test against it.
The bug happens in the parsing of the signature hash algorithm list that is sent in a ClientHello and is basically a textbook stack buffer overflow. WolfSSL simply tries to store that in an array with 32 elements. If one sends more than 32 hash algorithms it overflows.
With the SSL Labs scan the bug only causes WolfSSL to terminate if it's compiled with address sanitizer, but if one sends a very large list of hash algorithms it also crashes in a normal compile. In situations where WolfSSL is used without ASLR this bug is probably trivially exploitable.
I have created a simple bash proof of concept (using netcat and xxd) that crashes a WolfSSL server.
The bug was fixed in this commit and in version 3.13.0 of WolfSSL.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded