marcIhm / yabasic

Yabasic - A simple Basic interpreter for Unix and Windows
http://www.yabasic.de
MIT License
90 stars 17 forks source link

Heap-based buffer overflow in the myformat() function #37

Closed fcambus closed 4 years ago

fcambus commented 4 years ago

Hi,

While fuzzing yabasic 2.86.2 with Honggfuzz, I found a heap-based buffer overflow in the myformat() function, in function.c.

Attaching a reproducer (gzipped so GitHub accepts it): test02.yab.gz

Issue can be reproduced by running:

yabasic test02.yab
=================================================================
==20807==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x626000002814 at pc 0x00000043cce7 bp 0x7ffe28e0e900 sp 0x7ffe28e0e098
WRITE of size 41236 at 0x626000002814 thread T0
    #0 0x43cce6 in vsprintf (/home/fcambus/yabasic-2.86.2/yabasic+0x43cce6)
    #1 0x43dc73 in sprintf (/home/fcambus/yabasic-2.86.2/yabasic+0x43dc73)
    #2 0x4e4ad3 in myformat /home/fcambus/yabasic-2.86.2/function.c:1254:9
    #3 0x4ded27 in function /home/fcambus/yabasic-2.86.2/function.c:465:14
    #4 0x4d5717 in run_it /home/fcambus/yabasic-2.86.2/main.c:1779:17
    #5 0x4c5fe8 in main /home/fcambus/yabasic-2.86.2/main.c:325:9
    #6 0x7f664ab9b1e2 in __libc_start_main /build/glibc-4WA41p/glibc-2.30/csu/../csu/libc-start.c:308:16
    #7 0x41da2d in _start (/home/fcambus/yabasic-2.86.2/yabasic+0x41da2d)

0x626000002814 is located 0 bytes to the right of 10004-byte region [0x626000000100,0x626000002814)
allocated by thread T0 here:
    #0 0x49592d in malloc (/home/fcambus/yabasic-2.86.2/yabasic+0x49592d)
    #1 0x4c6314 in my_malloc /home/fcambus/yabasic-2.86.2/main.c:2099:12
    #2 0x4c5012 in main /home/fcambus/yabasic-2.86.2/main.c:122:23
    #3 0x7f664ab9b1e2 in __libc_start_main /build/glibc-4WA41p/glibc-2.30/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/fcambus/yabasic-2.86.2/yabasic+0x43cce6) in vsprintf
Shadow bytes around the buggy address:
  0x0c4c7fff84b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4c7fff84c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4c7fff84d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4c7fff84e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4c7fff84f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c4c7fff8500: 00 00[04]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4c7fff8510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4c7fff8520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4c7fff8530: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4c7fff8540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4c7fff8550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==20807==ABORTING
fcambus commented 4 years ago

This issue has been assigned CVE-2019-19796.

marcIhm commented 4 years ago

Thanx, this is fixed with version 2.86.3.