In json_parse_object(), there is a heap out-of-bound write. The bug can be triggered with an invocation of json_parse_ex() with specific flags combination. The root cause of this vulnerability is that the parser use value directly taken from state->dom as value_ex, while doesn't validate the bound of state->dom
Here is the output of Google ASAN when the vulnerability is triggerred:
The flags is 0x5fd628d6d6247bff
=================================================================
==4959==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6130000001b8 at pc 0x55f27037a5df bp 0x7fff30738e90 sp 0x7fff30738e88
WRITE of size 8 at 0x6130000001b8 thread T0
#0 0x55f27037a5de in json_parse_object /home/hyrathon/Desktop/jsonh/./json.h:1709:24
#1 0x55f27037b1c8 in json_parse_value /home/hyrathon/Desktop/jsonh/./json.h:1940:5
#2 0x55f270383c85 in json_parse_ex /home/hyrathon/Desktop/jsonh/./json.h:2129:3
#3 0x55f27039a192 in main /home/hyrathon/Desktop/jsonh/fuzz.c:29:5
#4 0x7f555df76d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#5 0x7f555df76e3f in __libc_start_main csu/../csu/libc-start.c:392:3
#6 0x55f2702a8314 in _start (/home/hyrathon/Desktop/jsonh/san+0x33314) (BuildId: a0e983e1c9c38a8763824dc5481f79d22fe8c82a)
0x6130000001b9 is located 0 bytes to the right of 377-byte region [0x613000000040,0x6130000001b9)
allocated by thread T0 here:
#0 0x55f27032b15e in __interceptor_malloc (/home/hyrathon/Desktop/jsonh/san+0xb615e) (BuildId: a0e983e1c9c38a8763824dc5481f79d22fe8c82a)
#1 0x55f270382f15 in json_parse_ex /home/hyrathon/Desktop/jsonh/./json.h:2088:18
#2 0x55f27039a192 in main /home/hyrathon/Desktop/jsonh/fuzz.c:29:5
#3 0x7f555df76d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/hyrathon/Desktop/jsonh/./json.h:1709:24 in json_parse_object
Shadow bytes around the buggy address:
0x0c267fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c267fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c267fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c267fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c267fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c267fff8030: 00 00 00 00 00 00 00[01]fa fa fa fa fa fa fa fa
0x0c267fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c267fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c267fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c267fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c267fff8080: 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
==4959==ABORTING
The input to trigger this bug is attached. The first 8 bytes are the flags for json_parse_ex() and the rest is the content(src). Please use address sanitizer to reproduce the bug, as non-crash overflow is hard to detect or locate without shadow memory.
I also attach the input that can cause the other overflow I mentioned.
Heap Overflow in json_parse_object()
In
json_parse_object()
, there is a heap out-of-bound write. The bug can be triggered with an invocation ofjson_parse_ex()
with specific flags combination. The root cause of this vulnerability is that the parser use value directly taken fromstate->dom
asvalue_ex
, while doesn't validate the bound ofstate->dom
Similar situation can also be found at:
Here is the output of Google ASAN when the vulnerability is triggerred:
The input to trigger this bug is attached. The first 8 bytes are the flags for
json_parse_ex()
and the rest is the content(src). Please use address sanitizer to reproduce the bug, as non-crash overflow is hard to detect or locate without shadow memory.I also attach the input that can cause the other overflow I mentioned.
crash1.zip