CVE-2015-0797 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-0797): GStreamer before 1.4.5, as used in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 on Linux, allows remote attackers to cause a denial of service (buffer over-read and application crash) or possibly execute arbitrary code via crafted H.264 video data in an m4v file. Missing stabilization for alpha and ia64
(stabilizing only gstreamer main package but not the plugins isn't a good idea from my point of view :|)
(In reply to Pacho Ramos from comment #1) > (stabilizing only gstreamer main package but not the plugins isn't a good > idea from my point of view :|) Thanks for the pointer, as long as the security fix is being applied I'm happy :)
But what exactly needs stabilizing?
(In reply to Tobias Klausmann from comment #3) > But what exactly needs stabilizing? gstreamer and its plugins as listed in bug 551814
So since the bug you linked is done, we can consider this done, too?
All fixed versions are stable... then, lets security team continue the pending job (glsa and all that). I guess we will need to clean the old vulnerable versions too when we have time ;)
Maintainer(s), please drop the vulnerable version(s). New GLSA Request filed.
Cleaned up.
Arches and Maintainer(s), Thank you for your work.
This issue was resolved and addressed in GLSA 201512-07 at https://security.gentoo.org/glsa/201512-07 by GLSA coordinator Yury German (BlueKnight).
Re-opening this bug as it seems likely the 0.10 slot is still affected by this vulnerability. From a rudimentary investigation it seems 0.10 is actually a separate upstream that is not activly maintained, so a patch will have to be backported if we want to keep 0.10 in stable still. @maintainers: can you comment on the applicability of this bug in 0.10?
I have no concrete idea where the bug happened. It seems the CVE and mozilla claimed it was fixed by 1.4.5, so we just finished stabilization of these and that's it. The mozilla bug is not viewable for me, at least not without making a bugzilla account there (and it suggests it's closed then too as a security bug still), so I can only assume it had to be in the h264parse element, which is part of the videoparsersbad plugin, which is shipped in gentoo with the media-libs/gst-plugins-bad package. So in that sense (IFF the issue is indeed in h264parse) the GLSA is wrong in the package it references, though they tend to all go in sync with slight enforcement (but not fully ensuring it) of it going on too across different packages. h264parse received absolutely no changes itself between versions 1.4.4 and 1.4.5, so I'm going to have to assume mozilla didn't really track down when the issue was resolved either. But maybe the issue was in another component, as I don't know. There were various changes to it between 1.4.3 and 1.4.4, but nothing that screams out as a security fix to me based on a cursory glance of the commit logs. By limiting the changes only to gsth264parse.* files, the changes to 1.4.4 were https://bugzilla.gnome.org/show_bug.cgi?id=739374 https://bugzilla.gnome.org/show_bug.cgi?id=732239 https://bugzilla.gnome.org/show_bug.cgi?id=737186 None of which based on the information there sound like a potential remote DoS, but who knows. I am understandably not willing to go looking blindly further back in the history. So in short, without knowing what the actual issue was nor having appropriately crafted video data, I can not assess if and how 0.10 is affected. Given that we already carry 6 patches from the 2011 and 2012 era in our gst-plugins-bad 0.10 package, specifically all for h264parse, I wouldn't be surprised that it's affected the same. 0.10 is not maintained upstream, it has been superseded by API/ABI breaking 1.x series (1.0, 1.2, 1.4 and 1.6 are all backwards compatible, however, the versioning went more traditional now) for 3 years now and not maintained upstream 2-3 years. It is sad that projects like Firefox are unable to move over to fully 1.x long ago - for example our Firefox maintainers added a gstreamer-0 USE flag to use gstreamer-0.10 instead of 1.4 or 1.6 due to apparent issues in their gstreamer:1.0 usage that happens to some people (bug 550828), so there are Gentoo users that are using Firefox with gst-plugins-bad-0.10 still. I'm not sure what firefox-bin does. Others are worrying about 0.10 security, with firefox and/or other stuff still using it for them - https://forums.gentoo.org/viewtopic-t-1036324.html
It was reported on gentoo-user that this has been patched in suse/debian: https://www.suse.com/security/cve/CVE-2015-0797.html https://www.debian.org/security/2015/dsa-3225 I assume their patches are easily accessible somewhere.
(In reply to Richard Freeman from comment #13) > It was reported on gentoo-user that this has been patched in suse/debian: > > https://www.suse.com/security/cve/CVE-2015-0797.html > > https://www.debian.org/security/2015/dsa-3225 > > I assume their patches are easily accessible somewhere. That should be https://sources.debian.net/data/main/g/gst-plugins-bad0.10/0.10.23-7.1+deb7u2/debian/patches/buffer-overflow-mp4.patch
(In reply to Kristian Fiskerstrand from comment #14) > https://sources.debian.net/data/main/g/gst-plugins-bad0.10/0.10.23-7.1+deb7u2/debian/patches/buffer-overflow-mp4.patch SUSE is using the same patch, https://build.opensuse.org/package/view_file/multimedia:libs/gstreamer-0_10-plugins-bad/gstreamer-0_10-plugins-bad-mp4-overflow.patch?expand=1
[master 155ea40] media-libs/gst-plugins-bad: Fix CVE-2015-0797, bug #553742 2 files changed, 85 insertions(+) create mode 100644 media-libs/gst-plugins-bad/files/gst-plugins-bad-0.10.23-CVE-2015-0797.patch create mode 100644 media-libs/gst-plugins-bad/gst-plugins-bad-0.10.23-r3.ebuild
Arches, please stabilize: =media-libs/gst-plugins-bad-0.10.23-r3 Stable targets: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
amd64 stable
Stable for PPC64.
Stable for HPPA.
arm stable
Stable on alpha.
ppc stable
I would like to again point out that it's unlikely that the issue in 1.x series was in media-libs/gstreamer itself, as the GLSA and bug title claims. h264parse is in gst-plugins-bad in 1.x versions still for now. In fact, I can't find anything resembling this code or fix in the 1.4 branch. There's the same function, but it doesn't have such nal_size checks in place like the patch adds. So I would have no idea if it's fixed there somehow different at a different place, not fixed at all, or what.
<leio> talking of which, what was that CVE from mozilla in h264parse mp4 parsing all about <leio> in particular, I can't track it down to any actual 1.x fix and they there just claimed 1.4.5 is fixed <leio> CVE-2015-0797 <leio> https://www.debian.org/security/2015/dsa-3225 <leio> slomo: 1.x wasn't ever affected really? <slomo> leio: nobody tracked it down iirc, it was fixed some time before 1.0.0 <leio> so I can say that it was never affected in any 1.x, so they can amend that advisory completely? <slomo> also nobody ever notified the gstreamer project about that problem beforehand, so whatever. can't have been that important if nobody thought it would be useful to talk to us <slomo> yes, iirc someone tested it with 1.2 a while ago and it didn't cause problems there other than some assertions (basically the problem simply doesn't happen already because of the better memory handling API in 1.0) <slomo> no idea if someone actually tested it with 1.0.0 <leio> can I just quote you verbatim? :P <slomo> leio: sure, i'm quite annoyed about this. security people making all the noise about this but not even considering to talk to the developers before making it public <slomo> leio: fwiw, the 0.10 patch in debian is not ideal. it's too strong, instead of just failing completely it could catch the actual problem and recover from that <slomo> leio: but as this is 0.10, whatever is there is good enough. it prevents the security relevant part of the problem at least As such, the GLSA about <media-libs/gstreamer-1.4.5 is completely wrong, not only for the package (gst-plugins-bad has the relevant gstreamer element), but none of the versions ever in 1.0 SLOT are known to have been affected. And only now with the recent gst-plugins-bad:0.10 SLOT=0.10 revbump we have an overly strict patch in there. Please amend appropriately. I shall also note that https://www.mozilla.org/en-US/security/advisories/mfsa2015-47/ linked off of the CVE clearly states that 1.0 versions are unaffected, so I don't know where this misunderstanding and mishandling in versioning originated from, or maybe that link has been amended by now too, but the CVE itself says earlier than 1.4.5, so I guess from there (no-one simply had ever tested anything older, it seems).
x86 done
Is there more to this or have I understood correctly that the security issue is fixed in media-libs/gst-plugins-bad-0.10.23-r3 for the 0.10 slot? Any chance the GLSA will be updated to reflect this soon? I'm not comfortable with GLSA claiming the system to be vulnerable if it is not...
(In reply to Fredrik Eriksson from comment #27) > Is there more to this or have I understood correctly that the security issue > is fixed in media-libs/gst-plugins-bad-0.10.23-r3 for the 0.10 slot? Yes, if you want to call it a security issue. Mozilla never talked to upstream. No 1.0 slot of any package was ever known to be vulnerable to this, definitely not gstreamer:1.0 as the GLSA claims, and also not gstreamer:0.10 as it ends up claiming due to no SLOT restrictions - many users might not even have gst-plugins-bad:0.10 installed at all and it wrongly claims vulnerability right now indeed. > Any chance the GLSA will be updated to reflect this soon? I'm not > comfortable with GLSA claiming the system to be vulnerable if it is not... Not sure what the GLSA guys workflow and free time is like. It should be telling that <media-libs/gst-plugins-bad-0.10.23-r3 is vulnerable, nothing else.
media-libs/gst-plugins-bad-0.10.23-r3 added to unaffected
The last change still reports that the system is affected by this GLSA. I have installed: media-libs/gst-plugins-bad-0.10.23-r3 media-libs/gstreamer-1.4.5 Both are unaffected according to the description. Additionally I have installed the 0.10-slot for gstreamer and the 1.0-slot for gst-plugins-bad . I suppose glsa-check detects the gstreamer-version from slot 0.10 and reports the problem because the version is obviously >=1.4.5 .
(In reply to poinck from comment #30) > The last change still reports that the system is affected by this GLSA. > > I have installed: > media-libs/gst-plugins-bad-0.10.23-r3 > media-libs/gstreamer-1.4.5 > > Both are unaffected according to the description. Additionally I have > installed the 0.10-slot for gstreamer and the 1.0-slot for gst-plugins-bad . > I suppose glsa-check detects the gstreamer-version from slot 0.10 and > reports the problem because the version is obviously >=1.4.5 . Thanks for notice, did yet another attempt at fixing the GLSA..
Thanks for the update, however it looks like media-libs/gstreamer:0.10 is still listed as affected. # glsa-check -p 201512-07 Checking GLSA 201512-07 >>> No upgrade path exists for these packages: media-libs/gstreamer-0.10.36-r2
(In reply to Fredrik Eriksson from comment #32) > Thanks for the update, however it looks like media-libs/gstreamer:0.10 is > still listed as affected. > > # glsa-check -p 201512-07 > Checking GLSA 201512-07 > >>> No upgrade path exists for these packages: > media-libs/gstreamer-0.10.36-r2 Sorry, please ignore this, I hadn't synced yet. Looks fine now, thank you.
(In reply to Kristian Fiskerstrand from comment #31) > Thanks for notice, did yet another attempt at fixing the GLSA.. GLSA now says: <affected> <package name="media-libs/gstreamer" auto="yes" arch="*"> <unaffected range="ge">1.4.5</unaffected> <unaffected range="rge">0.10.36-r2</unaffected> <vulnerable range="lt">1.4.5</vulnerable> </package> <package name="media-libs/gst-plugins-bad" auto="yes" arch="*"> <unaffected range="rge">0.10.23-r3</unaffected> <vulnerable range="lt">0.10.23-r3</vulnerable> </package> </affected> However NO version of media-libs/gstreamer has EVER been affected. Please nuke all of that media-libs/gstreamer portion, unless there is some reason for it for backwards compatibility purposes due to the GLSA having been published earlier or whatever; if that is the case, then ALL versions are unaffected, because media-libs/gstreamer does not contain any of the code in question. The gst-plugins-bad bits are now good.
To let @sec concentrate on new advisories and such, we agreed on IRC a while ago that it's fine to keep the GLSA tags now as-is. To get this bug marked FIXED, we just still need gst-plugins-bad-0.10.23-r3 stable on ia64 and sparc.
sparc stable
ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Removed vulnerable version.
GLSA was released and revised to account for the 0.10.23-r3 version.
