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 752495 - [SECURITY] _fallback_mem_copy may read before and after valid data
[SECURITY] _fallback_mem_copy may read before and after valid data
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-16 14:52 UTC by Sebastian
Modified: 2015-10-13 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian 2015-07-16 14:52:53 UTC
_fallback_mem_copy in gstallocator.c does not check the bounds of the requested copy.
1. The offset of the copy may be negative so reads starting before the valid data are possible.
2. (offset + size) are not checked to see if the sum falls outside the valid data region so data can be read from after the end of the buffer.

This lack of bounds checking poses a security risk as well as making gstreamer less robust.
Comment 1 Sebastian 2015-07-16 15:16:09 UTC
Also forgot the obvious: 
Since size parameter is signed then when passed to gst_allocator_alloc with a negative value - we may try to allocate huge amounts of memory which will probably crash the calling application
Comment 2 Sebastian Dröge (slomo) 2015-10-13 09:41:06 UTC
This would IMHO be a bug in other code that creates invalid memories. Did you run into this somehow?

Having some assertion in the fallback_mem_copy might still be useful, want to provide a patch?
Comment 3 Sebastian 2015-10-13 10:09:18 UTC
I ran into this when trying to properly understand allocations for my own plugins and allocators.

I didn't encounter any actual problems.

Unfortunately I don't know gstreamer well enough to suggest a patch that will fix this at all places that it needs to be fixed (I later found out that it is probably not just _fallback_mem_copy that assumes about memory pointers). And unfortunately I don't have the time to do it properly.
Comment 4 Sebastian Dröge (slomo) 2015-10-13 10:12:42 UTC
Ok, I think there's not really a problem per-se in fallback_mem_copy() here. It's as much a problem as passing wrong parameters to memcpy(). If someone wants to add some assertions that's ok, if not then so be it :)