The Fuzzing Project

A while ago I did a little experiment trying to fuzz the OpenSSL handshake with the intent to test whether Heartbleed could've been found with fuzzing. At some point while developing the sample code I discovered that american fuzzy lop would find a lot of crashes. However, on careful investigation I found that these were not due to bugs in OpenSSL, they were due to a bug in my test code: I didn't properly check for errors.

My code used TLSv1_method() to initialize the handshake. The packets the fuzzer created had a changed version number, so OpenSSL interpreted them as SSLv3 packets. OpenSSL wouldn't do a handshake with them and the function SSL_do_handshake() would return an error. However, as my code didn't check that error it later called SSL_do_handshake() again - and that will cause a crash. I've uploaded some example code to show this behaviour.

This is not really a bug in OpenSSL, but one may consider this as unexpected behaviour. OpenSSL has now changed that and the new code will not crash in that situation.

I wondered if other software would do similar mistakes and found out that trying to use the handshake packets in question on a dovecot mail server would cause crashes in the imap-login or pop3-login processes. However, I didn't analyze it further at that point.

Some time later I chattet with Aaron Zauner who is involved in a research project scanning for TLS server settings. He got feedback that their scans caused crashing dovecot processes, so I remembered my findings and reinvestigated the issue.

It turned out that on errors dovecot would try to finish the handshake. This caused the same error that I observed. I posted a detailed explanation on the dovecot mailing list, which is linked below. The dovecot developers have fixed this in release 2.2.17 (which was quickly followed by a 2.2.18 release due to unrelated bugs).

The crash is caused by a null pointer access. It is not exploitable. It can only be used to remotely crash server processes. As these login processes are automatically restarted by dovecot the impact is probably low.

Explanation on Dovecot mailing list
Upstream commit / patch
OpenSSL bug report
Dovecot 2.2.17 release notes
CVE-2015-3420

The Wireshark parser code for Android Logcat network packages contained a read heap overflow in the function detect_version().

This issue was reported to the Wireshark developers on May 5th. It was fixed in the 1.12.5 release of Wireshark, published on May 12th. The beta release 1.99.5 and the Git head code are not affected.

Apart from this issue Wireshark 1.12.5 fixes seven other security issues.

Wireshark 1.12.5 Release Notes
Wireshark bug #11188
Commit / fix
Sample pcap file triggering the overflow (test with tshark -r [input], can be seen with valgrind or address sanitizer)
CVE-2015-3815

While fuzzing SQLite I discovered two read heap overflow errors. One is in the database file parser, one in the sql command parser. Both issues are present in SQLite 3.8.9 and are fixed in SQLite 3.8.10.1. These bugs can be seen with either valgrind or address sanitizer.

Passing the command ".\" will cause a one byte heap overflow in the function resolve_backslashes().
Sample input file (test with sqlite3 < [inputfile])
Upstream commit / patch

Parsing a malformed database file will cause a heap overflow of several bytes in the function sqlite3VdbeExec(). This only matters if your attack scenario involves parsing untrusted database files.
Sample input file (test with sqlite3 [inputfile] .dump)
Upstream commit / patch

Please also note:
Finding bugs in SQLite, the easy way - Michal Zalewski fuzzed SQLite with a dictionary - most of these were already fixed in 3.8.9, the version I was testing.
SQL Fuzz Using The American Fuzzy Lop Fuzzer - SQLite developers themselve now use regular fuzz testing to find further bugs.
SQLite 3.8.10.1 release notes mention fixes for "many obscure problems discovered while SQL fuzzing", so there are likely more fixes than the two I mentioned above.