Two memory access issues were found in the Courier mail server. These issues were discovered by compiling the software with Address Sanitizer (-fsanitize=address) and running the test suite.
In the file mailboxlist.c, part of the IMAP folder parser, there is a memcmp call checking whether the fist six bytes of a string match "SHARED". However the string can be less than six bytes, which will cause an out of bounds read access. This issue is unlikely to cause much trouble.
In the mailbot tool (mailbot.c) there is a memory allocation for a zero-terminated list of pointers. The allocation only reserves one byte for the zero termination, however it must be the size of the pointer (8 bytes on 64 bit systems). Therefore it causes a write heap overflow of seven zero bytes. The code parses command line data, therefore it is unlikely that any attacker controlled input is affected.
Both issues have been reported to Courier's developer Sam Varshavchik on 27th June 2015 and were fixed with the release of courier 0.75 on 29th June 2015.
Commit / Patch (bundles some unrelated changes, the relevant parts are in mailbot.c and mailboxlist.c)
Courier 0.75 release announcement
I'm happy to announce today that the
Linux Foundation's Core Infrastructure Initiative has decided to financially support the work I'm doing for the Fuzzing Project. The Core Infrastructure Initiative (CII) was established last year after the Heartbleed bug in OpenSSL. A number of companies came together to support people improving the security of free and open source software.
For the Fuzzing Project this of course means that I will report many more bugs in the future. While in the beginning all the fuzzing work was done on my personal laptop I recently moved that to dedicated servers that fuzz applications all the time. Appart from that I'm investigating methods to further increase the ways to find bugs in large quantities. I have some preliminary experiments to use american fuzzy lop on network input. I also want to encourage developers of free software projects to get in touch with me if they think their project could profit from fuzz testing.
I also want to spend a few words on the other two projects that got supported by the CII.
One problem of free software is that you can in theory verify what the code is doing and check it for backdoors, but usually you don't compile the code yourself. You still get it in binary form from somewhere (unless you use a source-based system like Gentoo, but that's a small minority). In order to bridge this trust gap between source code and binaries the idea of reproducible builds emerged. If different people can compile the same code and will always get the same output then it can be independently verified that the code matches the binary. This is easier said than done, because you have to consider all kinds of non-deterministic behaviour, e. g. added timestamps, different compiler versions and more.
The
Debian Linux distribution is currently working on reproducible builds. Debian-developers Holger Levsen and Jérémy Bobbio (Lunar) will be supported by the CII and I am very optimistic that they will make it happen and the next Debian version will be reproducible. I am glad about this because I think if we really want trustworthy software in the future we need reproducible builds. I hope that in the future we can make it a norm that trustworthy, secure software contains a reproducible build process (which by definition means open code).
Pascal Cuoq is working on improving automated, formal methods to find bugs in software. He's worked on Frama-C before and he is currently working on a new code analyzer tool which is not public yet, but it already found
a number of potential issues in OpenSSL.
Lately I started an effort to systematically fuzz all possible file input vectors of OpenSSL. This led to the discovery of one potential security issue and two minor non-security fixes.
Malformed inputs can cause an out of bounds heap read access in the function X509_cmp_time. This issue was reported to the OpenSSL developers on 11th March. It was independently discovered three days earlier by Google developer Robert Swiecki.
During the fuzzing I also discovered several issues in the parser of ASN1 definition files. These can be used to create ASN1 data structures with OpenSSL. It is unlikely that there is any situation where ASN1 definitions are attacker controlled, therefore these are not considered security issues.
The latest security updates of OpenSSL (1.0.2b, 1.0.1n, 1.0.0s, 0.9.8zg) fix all three issues. These releases also fix a number of other security issues. Shortly after publishing these updates OpenSSL issued another update (1.0.2c, 1.0.1o), because the versions contained an ABI change which should not happen in minor releases.
I am aware that a couple of other people were also fuzzing OpenSSL lately. Noteworthy is
one issue that was found by Joseph Birr-Pixton in the parser of elliptic curve parameters. It is an endless loop and can be used to hang processes with a high CPU load. Endless loop issues tend to get ignored because they are often false positives.
It is definitely getting harder finding any new issues through fuzzing in OpenSSL. This is good news.
Out of bounds read in X509_cmp_time
CVE-2015-1789
Git commit / fix
OpenSSL Security Advisory
Sample malformed cert (test with openssl verify [input])
Samples for issues in ASN1 definition parser (test with openssl asn1parse -genconf [input]):
Out of bounds read heap
Stack overflow through endless recursion
Uninitialized memory access
Update: Around one year after these bugs were reported it turned out that one of the issues is actually
more severe than we thought.
The nghttp2 library ships two tools to parse http headers packed with the hpack algorithm. An invalid input file can crash the inflatehd tool. This is a bug in the tool, there is no issue in the library.
This issue was fixed in version 0.7.15 of nghttp2.
One day of fuzzing both the inflatehd and deflatehd turned up no other issues.
Sample input file
Git commit / patch
Upstream bug report
nghttp 0.7.15 release notes
uudecode is a tool to decode uuencoded data. It is shipped with the package
sharutils.
An invalid input file can cause an out of bounds stack read access in the function
expand_tilde(). This issue has been reported to the developers on 2015-03-04. It has been fixed in sharutils 4.15.2 (2015-05-30).
To see this bug one needs to use a tool like valgrind or address sanitizer that detects out of bounds memory reads. The bug was found with american fuzzy lop.
Sample file
Address sanitizer output:
==8209==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff8a4a8690 at pc 0x40738d bp 0x7fff8a4a44a0 sp 0x7fff8a4a4490
READ of size 1 at 0x7fff8a4a8690 thread T0
#0 0x40738c in expand_tilde /mnt/ram/sharutils-4.14/src/uudecode.c:252
#1 0x40738c in decode /mnt/ram/sharutils-4.14/src/uudecode.c:437
#2 0x403660 in main /mnt/ram/sharutils-4.14/src/uudecode.c:530
#3 0x7f13d97fff9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f)
#4 0x403c81 (/mnt/ram/sharutils-4.14/src/uudecode+0x403c81)
Address 0x7fff8a4a8690 is located in stack of thread T0 at offset 16800 in frame
#0 0x403da7 in decode /mnt/ram/sharutils-4.14/src/uudecode.c:362
This frame has 7 object(s):
[32, 36) 'mode'
[96, 104) 'outlen'
[160, 168) 'ctx'
[224, 368) 'attr'
[416, 16800) 'buf' <== Memory access at offset 16800 overflows this variable
[16832, 33216) 'buf_in'
[33248, 49632) 'buf'