After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 384996 - Tailored or broken Real Media mux file crashes RM demuxer
Tailored or broken Real Media mux file crashes RM demuxer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other All
: Normal critical
: 0.10.5
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-12-12 08:57 UTC by Roland Kay
Modified: 2006-12-12 10:27 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Malicious RM mux file designed to crash GStreamer. (100.10 KB, application/force-download)
2006-12-12 09:01 UTC, Roland Kay
  Details
check extra codec data size (2.07 KB, patch)
2006-12-12 09:32 UTC, Tim-Philipp Müller
committed Details | Review

Description Roland Kay 2006-12-12 08:57:13 UTC
Steps to reproduce:
1. Download the sample file (attached below)
2. Try to play in any app that uses GStreamer.
* bang *


Stack trace:
Don't pay too much attention to the stack trace; the cause is self-evident.
 
  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/libc.so.6
  • #2 abort
    from /lib/tls/libc.so.6
  • #3 g_logv
    from /opt/gnome/lib/libglib-2.0.so.0
  • #4 g_log
    from /opt/gnome/lib/libglib-2.0.so.0
  • #5 g_malloc
    from /opt/gnome/lib/libglib-2.0.so.0
  • #6 gst_buffer_new_and_alloc
    at gstbuffer.c line 289
  • #7 gst_rmdemux_parse_mdpr
    at rmdemux.c line 1391
  • #8 gst_rmdemux_chain
    at rmdemux.c line 1036
  • #9 gst_rmdemux_loop
    at rmdemux.c line 827
  • #10 gst_task_func
    at gsttask.c line 192
  • #11 g_thread_pool_free
    from /opt/gnome/lib/libglib-2.0.so.0
  • #12 g_static_private_free
    from /opt/gnome/lib/libglib-2.0.so.0
  • #13 start_thread
    from /lib/tls/libpthread.so.0
  • #14 clone
    from /lib/tls/libc.so.6
  • #15 ??


Other information:
Please see bug #384989.

The crash happens because rmdemux blindly believes the length field in the mux file. I've changed it from 0x00000008 to 0xffffffff. Thus, rmdemux.c tries to
allocate 4Gb of RAM for the data, which obviously fails:

rmdemux.c:1640:
         stream->extra_data_size = RMDEMUX_GUINT32_GET (data + offset + 74);
         stream->extra_data = (guint8 *) data + offset + 78;

rmdemux.c:1391:
      buffer = gst_buffer_new_and_alloc (stream->extra_data_size);
      memcpy (GST_BUFFER_DATA (buffer), stream->extra_data,
          stream->extra_data_size);

Note: The sample file contains a version 5 stream, so this should happen with CVS HEAD (i.e. without the patch submitted to bug #384989).
Comment 1 Roland Kay 2006-12-12 09:01:40 UTC
Created attachment 78191 [details]
Malicious RM mux file designed to crash GStreamer.

I've had to truncate the mux file because it was too large to attach. However, the effect is the same.
Comment 2 Tim-Philipp Müller 2006-12-12 09:32:36 UTC
Created attachment 78194 [details] [review]
check extra codec data size

Includes patch from bug #384989 to read the extra codec data size for stream version 4 instead of assuming it is always 16.
Comment 3 Tim-Philipp Müller 2006-12-12 10:27:08 UTC
> Includes patch from bug #384989 to read the extra codec data size for stream
> version 4 instead of assuming it is always 16.

Actually, not quite true, I forgot the offset adjustment for the codec data for version 4 streams (71 => 73). Fixed in the commit.

 
 2006-12-12  Tim-Philipp Müller  <tim at centricular dot net>

        Based on patch by: Roland Kay  <roland.kay at ox compsoc net>

        * gst/realmedia/rmdemux.c: (gst_rmdemux_parse_mdpr):
          For version 4 streams, read the extra codec data size from the
          header instead of assuming it is always 16 (also read it from the
          right position) (#384989). For version 4 and 5 streams, check that
          the specified extra codec data size doesn't make us read beyond the
          chunk boundary (#384989).