heap buffer overflow in iobuf.c
Closed, ResolvedPublic


Hi, I am working on a project in which I use the afl fuzzer and address sanitizer to find bugs in software. When fuzzing gpg I came across a heap buffer overread in common/iobuf.c on line 1275 when called as follows:
gpg --export --no-default-keyring --keyring <absolute path to file attached>
The bug is only visible when compiled with the address sanitizer.


jfe created this task.Feb 2 2018, 4:28 PM
werner triaged this task as Unbreak Now! priority.Feb 3 2018, 1:30 AM
werner added a subscriber: werner.Feb 14 2018, 4:54 PM

Can't replicate this with gcc's address sanitizer. I found a bug in kbxutil, though.
Can you post a bit more info than just line 1275?

jfe added a comment.Feb 14 2018, 9:44 PM

That's weird, I can reproduce it with a fresh pull from dev.gnupg.org (I can't clone it because it keeps giving me an error like "no rule to make target audit-events.h) by configuring with CFLAGS set to -fsantize=address -ldl and LDFLAGS set to -lasan. I added the -ldl because of a linking error with symbol dlsym (only when -fsantize=address is present). It more specifically complains about a READ access of size 1 and heap-buffer-overflow on address 0xb30037b0. It also mentions that this address is a wild pointer. The call tree looks as follows:

gniibe added a subscriber: gniibe.EditedFeb 15 2018, 7:37 AM

I guess that you are running on 32-bit architecture where the function keybox_get_keyblock uses 32-bit signed size_t for image_off and image_len.

I think that we need some checks for the keybox blob header.

jfe added a comment.Feb 15 2018, 10:34 AM

Yes, that is correct.

werner claimed this task.Feb 15 2018, 11:24 AM

Does this patch help? My artificial test confirmed that this does the Right Thing.

jfe added a comment.Feb 16 2018, 7:32 PM

This handles the problem, thanks.

jfe closed this task as Resolved.Feb 16 2018, 7:33 PM