Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read heap overflow in function _unmarshal_int32() #7

Open
hannob opened this issue May 13, 2015 · 1 comment
Open

Read heap overflow in function _unmarshal_int32() #7

hannob opened this issue May 13, 2015 · 1 comment

Comments

@hannob
Copy link

hannob commented May 13, 2015

This file will trigger a heap overflow in chmlib (test with enum_chmLib):
https://crashes.fuzzing-project.org/chmlib-heapoverflow-_unmarshal_int32.chm

To see this chmlib needs to be run with valgrind or compiled with address sanitizer. When address sanitizer is not used it will cause an infinite loop.

Found with the help of american fuzzy lop.

Address Sanitizer output:

==6078==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efe0 at pc 0x0000004e6b0a bp 0x7fff29013b00 sp 0x7fff29013af8
READ of size 1 at 0x60200000efe0 thread T0
#0 0x4e6b09 in _unmarshal_int32 /f/chmlib-0.40/src/chm_lib.c:264:13
#1 0x4e6b09 in _unmarshal_pmgl_header /f/chmlib-0.40/src/chm_lib.c:504
#2 0x4e5070 in chm_enumerate /f/chmlib-0.40/src/chm_lib.c:1663:15
#3 0x4dcc8e in main /f/chmlib-0.40/src/enum_chmLib.c:80:15
#4 0x7ffebbc90f9f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20/csu/libc-start.c:289
#5 0x4363d6 in _start (/mnt/ram/chmlib/enum_chmLib+0x4363d6)

0x60200000efe0 is located 0 bytes to the right of 16-byte region [0x60200000efd0,0x60200000efe0)
allocated by thread T0 here:
#0 0x4bd3a2 in __interceptor_malloc (/mnt/ram/chmlib/enum_chmLib+0x4bd3a2)
#1 0x4e4d5d in chm_enumerate /f/chmlib-0.40/src/chm_lib.c:1628:23
#2 0x4dcc8e in main /f/chmlib-0.40/src/enum_chmLib.c:80:15

SUMMARY: AddressSanitizer: heap-buffer-overflow /f/chmlib-0.40/src/chm_lib.c:264 _unmarshal_int32
Shadow bytes around the buggy address:
0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa 00 00[fa]fa fd fd
0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9e40: 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
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
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
==6078==ABORTING

@jedwing
Copy link
Owner

jedwing commented May 24, 2015

Thanks for the report. Looks like it should be a pretty simple fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants