Headline
CVE-2019-19786: ATasm: 6502 cross-assembler / Bugs
ATasm 1.06 has a stack-based buffer overflow in the parse_expr() function in setparse.c via a crafted .m65 file.
- Summary
- Files
- Reviews
- Support
- Wiki
- Tickets ▾
- Bugs
- Feature Requests
- News
- Code
- Discussion
Menu ▾ ▴
#9 Stack-based buffer overflow in the parse_expr() function
Status: closed
Owner: nobody
Labels: None
Priority: 5
Updated: 2021-03-20
Created: 2019-12-13
Private: No
Hi,
While fuzzing ATasm 1.08 with Honggfuzz, I found a stack-based buffer overflow in the parse_expr() function, in setparse.c.
Attaching a reproducer, issue can be reproduced by running:
================================================================= ==29838==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff079a8b00 at pc 0x0000004e0478 bp 0x7fff079a8a70 sp 0x7fff079a8a68 WRITE of size 1 at 0x7fff079a8b00 thread T0 #0 0x4e0477 in parse_expr /home/fcambus/atasm/src/setparse.c:83:13 #1 0x4e236d in get_signed_expression /home/fcambus/atasm/src/setparse.c:319:5 #2 0x4e08a5 in get_expression /home/fcambus/atasm/src/setparse.c:154:27 #3 0x4d3deb in proc_sym /home/fcambus/atasm/src/asm.c:1678:14 #4 0x4d5556 in do_cmd /home/fcambus/atasm/src/asm.c:1941:5 #5 0x4d5b46 in assemble /home/fcambus/atasm/src/asm.c:1980:9 #6 0x4d8082 in main /home/fcambus/atasm/src/asm.c:2392:3 #7 0x7fad7a5101e2 in __libc_start_main /build/glibc-4WA41p/glibc-2.30/csu/…/csu/libc-start.c:308:16 #8 0x41b3fd in _start (/home/fcambus/atasm/atasm+0x41b3fd)
Address 0x7fff079a8b00 is located in stack of thread T0 at offset 128 in frame #0 0x4dfd9f in parse_expr /home/fcambus/atasm/src/setparse.c:71
This frame has 2 object(s): [32, 36) ‘v’ (line 72) [48, 128) ‘expr’ (line 73) <== Memory access at offset 128 overflows 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/atasm/src/setparse.c:83:13 in parse_expr Shadow bytes around the buggy address: 0x100060f2d110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100060f2d120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100060f2d130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100060f2d140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100060f2d150: f1 f1 f1 f1 04 f2 00 00 00 00 00 00 00 00 00 00 =>0x100060f2d160:[f3]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x100060f2d170: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8 0x100060f2d180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x100060f2d190: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 0x100060f2d1a0: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 0x100060f2d1b0: 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 ==29838==ABORTING
1 Attachments
Discussion
Log in to post a comment.