Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • gstreamer gstreamer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 1.1k
    • Issues 1.1k
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 489
    • Merge requests 489
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gstreamergstreamer
  • Issues
  • #1226
Closed
Open
Issue created May 18, 2022 by Adam Doupe@adamdoupe

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

  1. Download
  2. 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.

Assignee
Assign to
Time tracking