Simon Kilvington discovered a vulnerability in FFmpeg libavcodec, which can be exploited by malicious people to cause a DoS (Denial of Service) and potentially to compromise a user's system. The vulnerability is caused due to a boundary error in the "avcodec_default_get_buffer()" function of "utils.c" in libavcodec. This can be exploited to cause a heap-based buffer overflow when a specially-crafted 1x1 ".png" file containing a palette is read. Xine-lib, xmovie, mplayer, gstreamer-ffmpeg might be built with a private copy of ffmpeg containing this same code. We should doublecheck them.
media-video herd, this one is for you :/
ouch, that's going to be a problem. Luca, ffmpeg is your stuff, what you suggest to do? xine-lib is going to hurt... a lot.. because of the usual keywording problems..
I guess that yet another snapshot is feasible even if ffmpeg is going to get a release soon
Created attachment 74873 [details, diff] patch proposed to upstream Just adding some stuff to keep everything in one place
Add vlc, mythtv, probably some others, too. ffmpeg-code is widely used and most times bundled.
Created attachment 74874 [details, diff] upstream fix That is the upstream fix. A new ffmpeg snapshot will be on route soon, for xine I'd either force external ffmpeg or bump to latest, considerations about killing xv on platform in which it couldn't be tested, thus preventing the bump, are the usual.
I'm actually not sure if xine-lib is vulnerable, as it does not use ffmpeg for png decoding but libpng instead.
vlc is safe, it uses external ffmpeg (as I'd like to do with xine-lib, too, but sigh it's difficult).
Get back what I said about xine-lib, as the problems seems not to be only with png. The patch applies fine on xine-lib 1.1.1 sources, so my plan for it would be: xine-lib-1.1.1-r2 that's copied from 1.1.1-r0 (no ffmpeg useflag so no dep on external ffmpeg) to be marked stable on all arches but mips (the problem that prevented 1.1.0-r6 to go stable on x86 is fixed in 1.1.1 series) xine-lib-1.1.1-r3 that's copied from 1.1.1-r1 (ffmpeg useflag for external ffmpeg) to remain ~arch for the arches that have 1.1.1-r1 in ~, and that should be tested by the other arches the old 1.0.x and 1.1.0-rX series would go away, a part mips and ~mips versions that would remain until mips is sorted out (I'd propose to remove the keywords and make sure that the tree is not broken by that, after use.masking xine on mips, as they have no way to do a constant maintenance on it).
New ffmpeg snapshot uploaded, will require some revdep-rebuild probably, please test it.
newer ffmpeg snapshot broke badly on xine-lib, I've committed -r2 and -r3 for it, and masked ffmpeg for testing.
Okay, xine-lib ebuilds are in place, ffmpeg is now unmasked, as lu_zero fixed it, vlc as I said uses the external copy linked dynamically so it has nothing to be fixed into. CCing gstreamer herd as media-video does not maintain gstreamer-ffmpeg and Cardoe for MythTV.
*** Bug 113160 has been marked as a duplicate of this bug. ***
Good work ! Splitting the bug into xine-lib+ffmpeg / the others so that we can already call for stable on the ready-ones... Are our mplayer and xmovie vulnerable ?
See stable marking for ffmpeg and xine-lib on bug 115849.
Putting back ffmpeg in this bug as it will probably need a backport so as not to break existing stable software requiring it (vlc?).
video herd: what's your position on the packages left (the ones under your herd, not the externally-maintained ones) ? Should we call for testing on ffmpeg ? What about the others (mplayer...) ?
I should apply the fix to mplayer since a newer release won't happen before the 25th ffmpeg should be ok anyway
OK splitting the bug for ffmpeg testing.
See ffmpeg stable testing on bug 116181
Luca: let me know about progress on mplayer.
Any ETA for the mplayer snapshot ? I need to know if we should send the xine-lib GLSA now or wait a little.
any news here?
I've masked xmovie for now, until someone else is going to fix it. I'm sorry but unless it's a threat on my life, I'd rather stay as far as possible from heroines packages.
Cardoe: only the masked 0.19_pre8554 contains the fix, should you : 1- unmask that version so that we call for stable testing on it 2- patch the current stable with the ffmpeg fix and call that the new stable candidate Note: lu_zero still wanted for mplayer fix and someone from gstreamer for the last package. Come on, we're getting very late on this one.
mplayer has a snapshot ebuild with the fix available. I will update it soon, please start testing it.
Not sure if zaheerm has much free time, so I patched gst-plugins-ffmpeg. The patched ebuilds are 0.8.7-r1 and 0.10.0-r1
gst-plugins-ffmpeg stable marking splitted to bug 119512
lu_zero: What's the ETA for mplayer-1.0.20060102 unmasking ? If not possible, we need a backport to current stable. cardoe: we need a decision on comment #25
Give me a week to update the snapshot and make arches mark it
Luca: sounds good. You may want to combine the fix for bug 122029 with this.
New MythTV is already in the tree and it's got this fixed in it.
mythtv stable marking handled on bug 123066
updated snapshot available, there are 2 new deps that could be tested and marked for alpha hppa and ia64: musepack and openal. Please test it, I'll update/fix it if there are problems.
arches please test latest mplayer snapshot and report success/failure... and mark stable if stable
mplayer-1.0.20060217 sparc stable, seems to work at least as well as the previous stable (if not better). However i've seen a kinky issue with the sound being b0rked playing some videos when using the old config - went away when nuking the old config dir.
Stable on x86 (X.X)
Stable on amd64.
stable on ppc64
ppc stable
Stable on alpha.
Sorry guys for the delay. I did oversee this bug. hppa stable now.
Ready for GLSA
GLSA 200603-03
