matroska: heap overwrite in gst_matroska_demux_add_wvpk_header
Describe the vulnerability
The vulnerability is an integer overflow in gst_matroska_demux_add_wvpk_header which leads to a heap overwrite.
The allocation of newbuf can overflow so if blocksize is very large.
newbuf =
gst_buffer_new_allocate (NULL, WAVPACK4_HEADER_SIZE + blocksize,
NULL);
Later in the function, memory is copied from our data to outdata (which is mapped from newbuf, and blocksize is used (which is very large)
memcpy (outdata, data, blocksize);
An interesting note is that this would be impossible to trigger because of the size check on blocks in gst_matroska_demux_check_read_size, which restricts ebml blocks to size MAX_BLOCK_SIZE:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c#L5332
However, you can get around this by using zlib to decompress a block that is < MAX_BLOCK_SIZE into something much larger.
Expected Behavior
Not segfault.
Observed Behavior
Segfault.
Setup
- Operating System: Ubuntu 20.04.4
- Device: Computer
- GStreamer Version: 1.16.2
Steps to reproduce the bug
- Download
- Run
gst-play-1.0 ./wvpk-crash.mkvwvpk-crash.mkv (note it takes awhile, roughly 20 seconds on my machine to crash).
How reproducible is the bug?
Always.
Impact
Heap overwrite. An attacker can survive the overwrite by careful massaging of the heap, and corrupt heap objects and heap metadata (I have done this part). This can lead to arbitrary code execution (although I have not done this part).
Additional Information
I'd like to request a CVE for this vulnerability.
Thank you, happy to help.