This will be my very first 0day release on this blog, because I highly doubt it is exploitable. It's a crash in unsquashfs - A tool to unpack squashed file systems.
I fuzzed the unsquashfs binary of debian's package squashfs-tools [0],[1] and the latest version of it seems buggy in the sense that a malicously prepared squashfs file will crash the unsquashfs binary.
For it to crash, it is sufficient to use the non-default argument -stat, i.e. $> unsqushfs -stat <path-to-file>.
root@hacking:/tmp/squashfs-tools/squashfs-tools# ./unsquashfs -stat ../../squashfs/crashes/id\:000000\,sig\:11\,src\:000031\,op\:havoc\,rep\:2
Found a valid SQUASHFS 4:0 superblock on ../../squashfs/crashes/id:000000,sig:11,src:000031,op:havoc,rep:2.
Creation or last append time Thu Jul 13 17:29:21 2006
Filesystem size 73464968921481216 bytes (71743133712384.00 Kbytes / 70061654016.00 Mbytes)
Compression unknown
Segmentation fault
A short analysis showed the following:
The binary has a static mapping of (de)compression algorithms that it can use to (de)compress squashfs files. A global struct holds the pointers to the respective (de)compression functions. If the package was compiled without the support for specific compression algorithms (e.g. without lzma here), the entry will contain 0x00000 (NULL) [2]. However, when instructing unsquashfs to show statistics about the file, it will read the compression algo from the file and without further checks try to call the decompression function (comp->uncompress) from the struct, which results in RIP=0x00000 and a segfault. See the stack strace below.
Stacktrace for scale:
#1 0x00005555555566f4 in compressor_uncompress (comp=0x5555555725e0
<lz4_comp_ops>, dest=0x7fffffffbba0, src=0x7fffffffbad0, size=0x3,
block_size=0x2000, error=0x7fffffffbb04) at compressor.h:65
#2 0x0000555555557c7a in read_block (fd=0x3, start=0x60, next=0x0,
expected=0x0, block=0x7fffffffbba0) at unsquashfs.c:704
#3 0x000055555555a153 in squashfs_stat (source=0x7fffffffe0d3
"squashfs/crashes/id\:000000\,sig\:11\,src\:000031\,op\:havoc\,rep\:2")
at unsquashfs.c:1673
#4 0x000055555555dff4 in main (argc=0x6, argv=0x7fffffffdcf8) at
unsquashfs.c:2730
You can download the instrumented binaries and crash files here: squashfs-fuzz.tgz.
I have messaged the debian-security mailinglist about this issue on the 15th of May, 2019. Never got a reply, so I'll release that now due to the low exploitability and impact.
UPDATE (06.06.2019): Just got an email from the Debian guys that I should reach out to the squashfs author directly.
UPDATE (07.06.2019): After forwarding the email upstream to the author, the bug was fixed in commit https://github.com/plougher/squashfs-tools/commit/832a7b9971053d4d741c3230f52e97afd250e956
[0] https://packages.debian.org/sid/squashfs-tools (version 1:4.3-12 at the time of writing)
[1] https://github.com/plougher/squashfs-tools (Latest commit 3197524 on Apr 15 at the time of writing)
[2] https://stackoverflow.com/questions/4080673/are-the-members-of-a-global-structs-in-c-initialized-to-zero