Bugzilla Bug 115760

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 an attachment (id=74873) [edit]
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 an attachment (id=74874) [edit]
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