Crashes in memcpy when decompressing fuzzed files

[Jacek Wielemborek]

Hi! Congratulations on making it to the main page of Hacker News! :) I read the comments and saw some people complain about crashes, so I tried your project out with afl-fuzz.

I basically only gave it one seed, which is a "hello" message compressed as bzip3. Within minutes, I got dozens of unique code paths that crash. Among the crash causes is SIGSEGV, which is a strong hint that there might be a security problem. Here's a look with a debugger:

(gdb) r -d o/crashes/id:000011,sig:11,src:000073,op:havoc,rep:4 /dev/stdout
Starting program: /bzip3/bzip3 -d o/crashes/id:000011,sig:11,src:000073,op:havoc,rep:4 /dev/stdout
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007f510ff06f35 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f510ff06f35 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000055cbb843d378 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>, __dest=<optimized out>, __src=<optimized out>, 
    __len=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29
#2  lzp_decompress (in=0x7f510d777010 '\377' <repeats 200 times>..., out=0x7f510f7da010 '\377' <repeats 200 times>..., n=<optimized out>, 
    lut=0x7f510ddd8010, m_len=40, hash=18) at src/lzp.c:212
#3  0x000055cbb84756c1 in bz3_decode_block (state=0x55cbb8c75670, buffer=0x7f510d777010 '\377' <repeats 200 times>..., data_size=<optimized out>, 
    orig_size=12662) at src/libbz3.c:239
#4  0x000055cbb8437e73 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:256

And the base16-encoded input case:

425a3376310000640000ffe70576310000425a337631720000ff31ff

Sometimes such errors can lead to arbitrary code execution, meaning that decompressing an untrusted archive leads to compromising the user's system. I cannot share all of the crashes with you, but I can assist you with setting up afl-fuzz and investigating the crashes. Anyway, please fuzz the project - otherwise claiming that it has been "extensively tested" is a bit of a dangerous thing to say.

[Kamila Szewczyk]

Hi! I have fuzzed the program myself, but I wasn't able to stumble upon this issue. I'll look at it shortly and I think I know what causes it.

To clarify, "extensively tested" means that I had tested if a round trip (hash => compress => decompress => hash) on the data works - the final corpus I put together was well over 100GiB. Fuzzing was a part of a later process which I had admittedly neglected a little.

[Kamila Szewczyk]

moved to #14.