Stack-based buffer overflow in the read_textobject() function
Xfig is a diagramming tool
Brought to you by:
tklxfiguser
Hi,
While fuzzing fig2dev with Honggfuzz, I found a stack-based buffer overflow in the read_textobject() function, in read.c.
Attaching a reproducer, issue can be reproduced by running:
fig2dev -L box test02
=================================================================
==5892==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc4aaefc62 at pc 0x000000439641 bp 0x7ffc4aaeb890 sp 0x7ffc4aaeb010
WRITE of size 628 at 0x7ffc4aaefc62 thread T0
#0 0x439640 in scanf_common(void*, int, bool, char const*, __va_list_tag*) (/home/fcambus/fig2dev-3.2.7b/fig2dev/fig2dev+0x439640)
#1 0x43a792 in __isoc99_sscanf (/home/fcambus/fig2dev-3.2.7b/fig2dev/fig2dev+0x43a792)
#2 0x4f53f1 in read_textobject /home/fcambus/fig2dev-3.2.7b/fig2dev/read.c:1331:10
#3 0x4e9e03 in read_objects /home/fcambus/fig2dev-3.2.7b/fig2dev/read.c:431:16
#4 0x4e7de6 in readfp_fig /home/fcambus/fig2dev-3.2.7b/fig2dev/read.c:172:12
#5 0x4e7bf8 in read_fig /home/fcambus/fig2dev-3.2.7b/fig2dev/read.c:142:13
#6 0x4dd35b in main /home/fcambus/fig2dev-3.2.7b/fig2dev/fig2dev.c:422:12
#7 0x7f6c5a2d61e2 in __libc_start_main /build/glibc-4WA41p/glibc-2.30/csu/../csu/libc-start.c:308:16
#8 0x41c6bd in _start (/home/fcambus/fig2dev-3.2.7b/fig2dev/fig2dev+0x41c6bd)
Address 0x7ffc4aaefc62 is located in stack of thread T0 at offset 16962 in frame
#0 0x4f4d5f in read_textobject /home/fcambus/fig2dev-3.2.7b/fig2dev/read.c:1304
This frame has 5 object(s):
[32, 40) 't' (line 1305)
[64, 8256) 's' (line 1307)
[8512, 16704) 's_temp' (line 1307)
[16960, 16962) 'junk' (line 1307)
[16976, 16980) 'num' (line 1400) <== Memory access at offset 16962 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/fcambus/fig2dev-3.2.7b/fig2dev/fig2dev+0x439640) in scanf_common(void*, int, bool, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
0x100009555f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555f60: 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2
0x100009555f70: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
=>0x100009555f80: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2[02]f2 f8 f3
0x100009555f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100009555fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==5892==ABORTING
Thanks for your report. The bug can only be reproduced when fig2dev was compiled with the -fsanitize=address option. Commit [19db5f] fixes this issue, I believe.
Related
Commit: [19db5f]
Indeed both 3.2.6a and 3.2.7b are safe here
This issue got assigned CVE-2019-19555.
Indeed, on Linux the bug is only triggered when sanitizers are enabled.
On OpenBSD however, it crashes with a normal build:
I can confirm that your patch fixes the issue with this test file, thanks!