AddressSanitizer: heap-buffer-overflow in alloc.c 246:11 in vim/vim
Reported on
Nov 24th 2022
Description
================================================================= ==19339==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x606000001015 at pc 0x0000004872d8 bp 0x7ffdef721150 sp 0x7ffdef720910 WRITE of size 2 at 0x606000001015 thread T0 [Detaching after fork from child process 19343] #0 0x4872d7 in strcpy (/root/vim2/vim/src/vim+0x4872d7) #1 0x2a2413c in vim_regsub_both /root/vim2/vim/src/regexp.c:2047:3 #2 0x2a3cf03 in vim_regsub_multi /root/vim2/vim/src/regexp.c:1963:14 #3 0x1207033 in ex_substitute /root/vim2/vim/src/ex_cmds.c:4645:9 #4 0x12a5cb4 in do_one_cmd /root/vim2/vim/src/ex_docmd.c:2578:2 #5 0x12694b7 in do_cmdline /root/vim2/vim/src/ex_docmd.c:990:17 #6 0x2ef7a83 in do_source_ext /root/vim2/vim/src/scriptfile.c:1667:5 #7 0x2eecaa6 in do_source /root/vim2/vim/src/scriptfile.c:1811:12 #8 0x2eecaa6 in cmd_source /root/vim2/vim/src/scriptfile.c:1163:14 #9 0x12a5cb4 in do_one_cmd /root/vim2/vim/src/ex_docmd.c:2578:2 #10 0x12694b7 in do_cmdline /root/vim2/vim/src/ex_docmd.c:990:17 #11 0x4a87f1b in exe_commands /root/vim2/vim/src/main.c:3138:2 #12 0x4a87f1b in vim_main2 /root/vim2/vim/src/main.c:781:2 #13 0x4a5dab7 in main /root/vim2/vim/src/main.c:432:12 #14 0x7f12e8717082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #15 0x4209ed in _start (/root/vim2/vim/src/vim+0x4209ed)
0x606000001015 is located 0 bytes to the right of 53-byte region [0x606000000fe0,0x606000001015) allocated by thread T0 here: #0 0x49bc4d in malloc (/root/vim2/vim/src/vim+0x49bc4d) #1 0x4cd87b in lalloc /root/vim2/vim/src/alloc.c:246:11
SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/vim2/vim/src/vim+0x4872d7) in strcpy Shadow bytes around the buggy address: 0x0c0c7fff81b0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x0c0c7fff81c0: fd fd fd fd fd fd fd fa fa fa fa fa 00 00 00 00 0x0c0c7fff81d0: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 fa 0x0c0c7fff81e0: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa 0x0c0c7fff81f0: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00 =>0x0c0c7fff8200: 00 00[05]fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0c7fff8210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0c7fff8220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0c7fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0c7fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0c7fff8250: 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 ==19339==ABORTING [Inferior 1 (process 19339) exited with code 01]
Proof of Concept
https://github.com/fondxd/fuzzing-poc/blob/8ca109aa2ecd314ef8f524db4a33cb10f08a890a/poc11
Impact
The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable.
in the poc line 3 the 2 symbols ^O represents digraph SI (SHIFT IN (SI)) Followed by ^W digraph EB (END OF TRANSMISSION BLOCK (ETB))
I can reproduce the problem. The POC is messy, the essential part is using CTRL-W gf in the expression used in the RHS of the substitute command editing another buffer. That is not allowed.
