Use of uninitialized memory in gf_gz_decompress_payload_ex()

[Heinzeen]

Description
Function gf_gz_decompress_payload_ex() passes uninitialized buffer data to the function inflate() (through d_stream.next_in)

Details
In box_funcs.c:118 size is read from the input. This value is then used to allocate memory ( in box_funcs.c:198); the allocated buffer should be initialized by the function gf_bs_read_data() in box_funcs.c:202 but the return value of this function (i.e. the number of read bytes) is not checked. Regardless of how many bytes are read, the whole buffer and the size variable are passed to the function gf_gz_decompress_payload_ex() in box_funcs.c:203 which then passes the (uninitialized) buffer to the function inflate() in base_encoding.c:254.

A possible fix might be to check the return value of the function gf_bs_read_data() in box_funcs.c:202 and either exit with an error or adjust the values accordingly if the expected size does not match the number of read bytes. The testcase provided in the PoC is only 10 bytes long, but triggers an allocation of millions of bytes since the first bytes appear to be interpreted as the size of the payload. The return value of the function gf_bs_read_data() with the given input is 0.

To Reproduce
The attached archive contains:

• the executable on which we performed our tests (commit hash: 205bfe3)
• the input file to exercise the bug
• the stacktrace when the bug was observed
• the output of Valgrind confirming our finding

At least for this testcase, a memory safety tool is required to expose the bug. To reproduce, run the given binary with the testcase file inside valgrind with a command like valgrind --track-origins=yes ./fuzz_parse uninit_mem/testcase.

The binary in the archive is a compiled version of the fuzzing harness you made available for OSS-Fuzz (i.e. testsuite/oss-fuzzers/fuzz_parse.c), with a main() function that simply opens a file, reads its content and calls the LLVMFuzzerTestOneInput() function. To compile, we used clang 14 and we ran every test on an ubuntu 22.04 x86-64 machine.

Impact
Use-of-uninitialized-memory violations can lead to security issues, but we could not assess the potential impact of this one in depth. We believe the severity (e.g., a local DoS from crash) will depend also on how erratically inflate() may behave on the random data from the uninitialized buffer. Since the testcase we generated does not cause a cash, we followed your policies in SECURITY.md and reported it here.