The Fuzzing Project

I think it's time for some status updates from the Fuzzing Project.

In a few days I'll be at the 31C3 congress in Hamburg. I'll have a short lightning talk about the Fuzzing Project there. I'll also be at Real World Crypto a few days later in London. Of course I'm always happy to discussing fuzzing efforts or other IT security related issues.

The webpage now has a three part tutorial covering zzuf, Address Sanitizer and american fuzzy lop. I hope it helps to teach more people how to find bugs and security issues.

Recently I could move two applications from the "work in progress" category to the "ok" category: elfutils and unrtf. For both of them it was easy to fuzz issues a few weeks ago, but their developers did a good job in fixing all issues I reported. They recently released new versions with all the fixes applied.

I'm regularly trying to find and report more fuzzing-related issues, lately for example in file/libmagic, flac, nasm and ndisasm. mkvtoolnix (libebml and libmatroska), poppler, libwpd.

I'm glad to see that the topic seems to gain more attention. I start to see fuzzing-related fixes mentioned in changelogs of various software projects.

While in many cases reported issues get fixed quickly and we get better software there are a few projects I find worriesome. This includes unzip which is a widely used zip unpacking code. Just by looking at their forum you'll find various memory corruption issues, some of them reported years ago, that have not seen a fix in a release. Recently oCERT released an advisory with three security vulnerabilities found by Google, still no fixed version. I'm also still waiting for any reply from the less developers to my recent report about an out of bounds memory access issue. They released a new version in the meantime, it doesn't contain a fix.

PDF rendering is generally known to be a security sensitive area. Given that it makes me feel uneasy that there is a large number of memory access bugs reported in their bug tracker and no sign of any effort to fix them.

An out of bounds read access in the UTF-8 decoding can be triggered with a malformed file in the tool less. The access happens in the function is_utf8_well_formed (charset.c, line 534) due to a truncated multibyte character in the sample file. It affects the latest upstream less version 470. The bug does not crash less, it can only be made visible by running less with valgrind or compiling it with Address Sanitizer. The security impact is likely minor as it is only an invalid read access.

This issue has been found with the help of Address Sanitizer.

The upstream developers have been informed about this issue on 4th November 2014, no fix is available yet. The less webpage has no bug tracker, no open mailing list and no other way to publicly report and document bugs.

Conclusion

Even tools that only do very minor file parsing can expose bugs due to charset encoding, especially in multibyte characters. Please note that the bigger security threat in less comes from the use of lesspipe.

It is unsettling that the upstream project of an important tool like less is completely unresponsive to bugs and has no public way to discuss them.

less out of bounds read sample with gif header
simpler sample with no header, only works when LESSOPEN is not set
OSVDB 115007 : less GIF File Handling Out-of-bounds Read Issue
Discussion of lesspipe security issues on oss-security
CVE-2014-9488

Update 2014-12-15: less released a new version 471 and this issue is not fixed.

Update 2015-03-10: Version 475 of less contains a fix for this issue. I never received any reply from the developers.

less doesn't have public release announcements or a repository, so it's hard to track their changes. The file version.c contains some entry mentioning this issue (without any credit):
v475 3/2/15 Fix possible buffer overrun with invalid UTF-8

The fix is in the file charset.c. Here is a patch.

Update 2015-06-03: It has been pointed out in the comments that the patch I provided was wrong (it was an unrelated fix for another issue). I have replaced it with the correct patch now. Also for clarification it should be pointed out that the latest "stable" version (according to the less webpage) 458 is not affected.

Fuzzing GnuPG uncovered a couple of issues with potential security impact. All issues found with american fuzzy lop and Address Sanitizer.

Buffer Overflow in OID decoding

A Buffer Overflow has been found in the OID decoding function with malformed OIDs. The code is shared between GnuPG and libksba. libksba is used for OID decoding by gpgsm and dirmngr. In GnuPG the error can be triggered by using the --list-packets parameter on the fuzzing sample.

The bug can be used for Denial of Service. Code execution is unlikely but cannot be ruled out.

Affected are GnuPG 2.1.0 and its beta versions and all libksba versions before 1.3.2. The issue is fixed in libksba 1.3.2 and will be fixed in the soon to be released GnuPG 2.1.1. GnuPG 2.0.x and 1.x versions are not affected.

libksba 1.3.2 release announcement
GnuPG commit / patch
libksba commit / patch
Fuzzing sample
CVE-2014-9087

Multiple invalid memory access issues

Malformed packets can cause access to uninitialized variables and an off by one access with --list-packets. A NULL pointer dereference can happen on --verify (already independently discovered and fixed). A malformed encrypted packet causes a call to BUG() (no security impact, just a funny error message). Likely all minor issues.

GnuPG commit / patch for uninitialized variable access
GnuPG commit / pach for NULL pointer deref
GnuPG commit / patch for off-by-one
Fuzzing sample uninitialized variable access
Fuzzing sample off-by-one
Fuzzing sample NULL pointer deref

All issues have been privately reported to GnuPG developer Werner Koch on 2014-11-23/24/25 who quickly fixed them.

Conclusion

More people should fuzz GnuPG.

From time to time The Fuzzing Project will post advisories for security issues.

Not all issues will be posted. The focus will be on interesting issues and issues with unsatisfying upstream reactions.