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);

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c#L3980

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);

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c#L4002

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.

Admin message