Skip to content

Stack overflow in libtasn1 (TFPA 002/2015)

libtasn1 is a library to parse ASN.1 data structures. Its most prominent user is GnuTLS.

Fuzzing libtasn1 led to the discovery of a stack write overflow in the function _asn1_ltostr (file parser_aux.c). It overflows a temporary buffer variable on certain inputs. This issue has been reported to the developers on 2015-03-26. A fix was released on 2015-03-29.

The issue can be exposed with Valgrind or Address Sanitizer. The Address Sanitizer output with detailed info is given below.

Git commit / fix
Release notes libtasn1 4.4
Sample input for stack overflow (to be used with examples/pkix.asn from libtasn1 source, e.g. src/asn1Decoding examples/pkix.asn TFPA-2015-002-libtasn1-4.3-stack-overflow.crt PKIX1Implicit88.Certificate)

An earlier fuzzing effort led to the discovery of a null pointer derefenence error in the ASN.1 definition parser. This is unlikely to have any security impact. Null pointer errors are usually not exploitable and there are probably no scenarios where ASN.1 definitions are attacker controlled. This issue has been reported to the libtasn1 developers on 2015-01-25 and was fixed on 2015-02-05. The fix was delivered with the 4.3 release of libtasn1.

Report on mailing list
Git commit / fix
Sample input for null ptr (can be tested with asn1Decoding TFPA-2015-002-libtasn1-4.2-null-ptr.asn x x)

I want to thank libtasn1 developer Nikos Mavrogiannopoulos for the quick fixes. Both issues were found with american fuzzy lop.

==4372==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff85a08084 at pc 0x43c180 bp 0x7fff85a07d10 sp 0x7fff85a07d00
WRITE of size 1 at 0x7fff85a08084 thread T0
#0 0x43c17f in _asn1_ltostr /data/libtasn1/libtasn1-4.3/lib/parser_aux.c:574
#1 0x41ee31 in _asn1_get_objectid_der /data/libtasn1/libtasn1-4.3/lib/decoding.c:397
#2 0x41ee31 in asn1_der_decoding2 /data/libtasn1/libtasn1-4.3/lib/decoding.c:1225
#3 0x423b0e in asn1_der_decoding /data/libtasn1/libtasn1-4.3/lib/decoding.c:1602
#4 0x403692 in simple_decode /data/libtasn1/libtasn1-4.3/src/asn1Decoding.c:251
#5 0x403692 in decode /data/libtasn1/libtasn1-4.3/src/asn1Decoding.c:280
#6 0x403692 in main /data/libtasn1/libtasn1-4.3/src/asn1Decoding.c:205
#7 0x7f94cb39af9f in __libc_start_main (/lib64/
#8 0x4046a1 (/data/libtasn1/libtasn1-4.3/src/asn1Decoding+0x4046a1)

Address 0x7fff85a08084 is located in stack of thread T0 at offset 564 in frame
#0 0x419bdf in asn1_der_decoding2 /data/libtasn1/libtasn1-4.3/lib/decoding.c:980

This frame has 10 object(s):
[32, 36) 'len2'
[96, 100) 'tag_len'
[160, 164) 'len2'
[224, 232) 'p'
[288, 296) 'p2'
[352, 360) 'ptail'
[416, 424) 'p'
[480, 489) 'temp'
[544, 564) 'temp' <== Memory access at offset 564 overflows this variable
[608, 736) 'temp'

Multiple issues in GnuPG found through keyring fuzzing (TFPA 001/2015)

A complex tool like GnuPG has many ways to parse input data. I previously had fuzzed GnuPG which had led to the detection of a Buffer Overflow vulnerability in GnuPG and libksba (CVE-2014-9087) and various other minor issues. Recently I tried to fuzz less obvious inputs of GnuPG: Keyrings and configuration files.

GnuPG allows to specify a non-standard keyring on the command line. Fuzzing GPG with
gpg --export --no-default-keyring --keyring [input keyring]
led to the detection of various issues. (Please note that the keyring parameter needs the full path and does not like filenames with unusual characters like the ones generated by american fuzzy lop.)

NULL pointer deref in parse_trust (parse-packet.c);a=commit;h=39978487863066e59bb657f5fe4e8baab510da7e

NULL pointer deref in do_key (build-packet.c);a=commit;h=0835d2f44ef62eab51fce6a927908f544e01cf8f

Use after free (build-packet.c);a=commit;h=f0f71a721ccd7ab9e40b8b6b028b59632c0cc648

memcpy with overlapping ranges (keybox_search.c);a=commit;h=2183683bd633818dd031b090b5530951de76f392

All issues found with american fuzzy lop. Fuzzing of the configuration file parser showed no issues.

While keyrings are usually not user-submitted data, some of these can be reached through other code paths. None of the issues looks severe, however judging the exact security would require further analysis.

2015-02-06 Reported three issues to GnuPG developer Werner Koch
2015-02-09 ALl reported issues fixed in git
2015-02-09 Reported one more issue to Werner Koch
2015-02-11 Last issue fixed in git
2015-02-11 Release of GnuPG 2.1.2 containing all fixes

less out of bounds read access - TFPA 002/2014

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.


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

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.

Buffer overflow and other minor issues in GnuPG and libksba - TFPA 001/2014

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

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.


More people should fuzz GnuPG.