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.