While fuzzing GnuTLS I discovered a malformed certificate input sample that would cause a heap overflow read of 99 bytes in the DER decoding functions of Libtasn1. The heap overflow happens in the function
_asn1_extract_der_octet().
This issue was reported to the Libtasn1 developer on 16th April. A fix was committed on 20th April and is part of the Libtasn1 4.5 release. This issue was found with american fuzzy lop and address sanitizer.
Git commit / fix
Libtasn1 4.5 release notes
Sample malformed certificate exposing heap overflow (test with
certtool -i --inder --infile=[sample] and address sanitizer or valgrind)
CVE-2015-3622
Today version 7.42.0 of curl was released. It fixes two vulnerabilities and one not security relevant bug that I found via fuzzing and reported.
When fuzzing an application the question is always which input vector you fuzz. The tool american fuzzy lop is purely file-based, therefore one needs some kind of file input to fuzz an application. Curl has a couple of potentially interesting file inputs.
One feature of curl is to save cookies to a file and later re-use that cookie file for followup connections. By fuzzing these inputs I found out that using a double-quote character (") as the path causes a memory access to a -1 index of an array. This could also be triggered by a malicious webpage.
The other input vector I fuzzed was the config file. Usually config files are not attacker-controlled, so one may question whether this makes sense at all. But here's what happened: The config file allows to pass an URL to curl and by that I found an out ouf bounds memory access in the URL parser. And an URL can be attacker controlled in many situations (for example through HTTP forwards). So the takeaway message here is that testing input vectors that are never attacker controlled (like config files) may still uncover potential security issues, because they might trigger code paths that matter in other situations.
All issues were reported to the curl security team on 16th April 2015 and are fixed in curl 7.42.0. Thanks to Daniel Stenberg of the curl team who quickly fixed all the issues I reported. Please also note that curl 7.42.0 fixes two other unrelated security issues.
cookie parser out of boundary memory access (cURL Security Advisory)
Patch
Git commit
CVE-2015-3145
Sample file (test with curl -b)
host name out of boundary memory access (cURL Security Advisory)
Patch
Git commit
CVE-2015-3144
Sample file (test with curl -K on the sample or just curl :0
Git commit for non-security config file parser issue
Sample file (test with curl -K)
GnuPG is a popular E-Mail encryption solution. GnuPG also ships a tool gpgsm that can be used to sign and encrypt mails according to the S/MIME standard. To parse S/MIME data structures the library libksba is used. GpgOL is a GnuPG-based plugin to use OpenPGP-encryption in Microsoft Outlook.
Fuzzing various input vectors of GnuPG led to the discovery of several potential security issues.
An integer overflow in the BER decoder of libksba can lead to an invalid write / heap overflow. This is fixed in libksba 1.3.3.
Git commit / fix
Sample file (test with
gpgsm --verify)
An invalid UTF-8 encoding can cause an assert in libksba. This may be abused to crash / DoS an application. This is fixed in libksba 1.3.3.
Git commit / fix
Sample file (test with
gpgsm --verify)
A stack overflow in an internal stack of the BER decoder of libksba can be abused to crash / DoS an application. This is fixed in libksba 1.3.3.
Git commit / fix
Sample file (test with
gpgsm --verify)
An invalid mail header can cause an off by one read access / heap overflow in the tool gpgparsemail, which is part of GnuPG. The same code is present in GpgOL, a plugin to use OpenPGP encryption in Microsoft Outlook. The gpgparsemail issue is fixed in GnuPG 2.1.3. There is no new release of GpgOL yet.
(Due to an incomplete fix there are two commits each.)
Git commit 1 for gpgparsemail / GnuPG
Git commit 2 for gpgparsemail / GnuPG
Git commit 1 for GpgOL
Git commit 2 for GpgOL
Sample file for original issue
Sample file for incomplete fix
A malformed packet could cause GnuPG to detect a negative packet length. The size variable is unsigned, resulting in an malloc call to a very large value and a crash / DoS. This is fixed in GnuPG 2.1.3.
Git commit / fix
Sample file for malloc DoS (test with
gpg --import or
gpg --list-packets)
A malformed private key can cause a null pointer access when trying to import the key. This came too late for GnuPG 2.1.3 and is not yet fixed in a release.
Git commit / fix
Sample file (test with
gpg --verify)