Denial of Service in Dovecot and unexpected crashes in OpenSSL (TFPA 008/2015)
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
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
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded