[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAE-dkstC2zp20DUosQ-2CfHf+f=Lj1vz+0JsA9vp42dX8FufLQ@mail.gmail.com>
Date: Thu, 21 Jan 2021 08:30:17 +0900
From: Andrew Wesie <andrew@...ori.io>
To: oss-security@...ts.openwall.com
Subject: CVE-2021-3185 gstreamer: buffer overflow in gst_h264_slice_parse_dec_ref_pic_marking
Hello all,
During a source code audit, Theori discovered a stack buffer overflow
in the h264parse module which is part of gstreamer-plugins-bad 1.x.
The vulnerable code path can be triggered when gstreamer parses any
attacker-controlled H.264 content. This flaw could lead to remote code
execution.
The flaw was fixed by the GStreamer project in gstreamer 1.18.1 and
gstreamer 1.16.3:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1703
CVE-2021-3185 was assigned for this issue.
Affected versions:
gstreamer 1.x before 1.18.1 and 1.16.3
Technical details:
There is a stack buffer overflow in
gst_h264_slice_parse_dec_ref_pic_marking when parsing a H.264
bitstream. There is no bounds check on the index variable,
dec_ref_pic_m->n_ref_pic_marking, and the destination array,
dec_ref_pic_m->ref_pic_marking, has a fixed size of 10 elements. The
fix is to check that the index variable does not go past the end of
the array.
The overflown array is within a GstH264DecRefPicMarking structure
allocated on the stack in gst_h264_parse_process_nal as part of a
GstH264SliceHdr structure. This leads to the usual stack buffer
overflow exploitation techniques, and to the possibility of an
attacker overflowing the array to modify other fields within
GstH264SliceHdr without triggering a stack canary.
The overflown array type is an array of GstH264RefPicMarking
structures. The attacker can only control one field of the structure
for each element. However, since the index variable is a byte, an
attacker can cause the index variable to wrap around and fill in
additional fields within each element. The attacker can also choose to
use an unhandled operation field value so that they do not overwrite
some portions of the stack memory. It is theoretically possible an
attacker could use this to "jump" over the stack canary and avoid
triggering an abort.
This vulnerability was discovered by Theori during a source code audit
for a customer who uses gstreamer. We were able to exploit this
vulnerability to achieve remote code execution in their environment.
They were using only partial ASLR and not using stack canaries; we
believe that exploitation would've been significantly more difficult
on a modern desktop Linux distribution.
Distributions shipping older branches of gstreamer 1.x should backport
the fix. We believe that any version of gstreamer 1.x before the fix
was committed will be vulnerable.
--
Andrew Wesie
Theori
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
