Bugzilla Bug 133520

Moritz Muehlenhoff from Debian found several patches in upstream CVS to fix
buffer overflows.

Filing as auditing as I'm not sure wether they are actually exploitable.

Created an attachment (id=86870) [details]
ffmpeg1.diff

Created an attachment (id=86871) [details]
ffmpeg2.diff

Created an attachment (id=86872) [details]
ffmpeg3.diff

Created an attachment (id=86873) [details]
ffmpeg4.diff

one or two look harmless, but the others look exploitable, reassigning to
vulnerabilities.

Luca please patch as necessary. Since this is only semi-public, please only
mention the bug number in the Changelog.

I'm looking at them right now

A new snapshot will be provided soon

Thx Luca,

Setting to upstream while waiting for the new snapshot.

quick snapshot available, requires full testing, the maketest _should_ fail on
ffserver but MUST work on codecs.

Several other packages repackage ffmpeg code also. Might need to get our mmedia
guys to take a closer look at the pkgs they maintain.

CC'ing Diego for advise as well.

vlc uses external ffmpeg, but xdtv uses it internal (they won't provide me a
way to use it external :|); xine might use both, and if I'm just tired, I can
disabled the external ffmpeg and be done with it at this point. Especially
since the few issues of conflicts between ffmpeg and xine are now fixed in -r6
(with GCC 3.4 and later).

Orig posting by Moritz Muehlenhoff.

Hi,
a quick heads-up; in the ffmpeg CVS logs I found changes mentioning several
potential buffer overflows. I haven't had the time to investigate
exploitability
in detail yet, though.

This might even affect you if you don't ship ffmpeg in one of your products,
as parts of ffmpeg (libavcodec and libavformat) are embedded in other
multimedia
applications (at least xine-lib and mplayer do).

Cheers,
        Moritz

Luca : can we call for stabilization of this last snapshot ?

I'd like every arch to test it, probably I'll resnapshot it to push more fixes
in (some security related), still there won't be as many changes as those
between the current stable and this candidate.

Pulling in security arch contacts for pretesting of the 0.4.9_p20060517
snapshot

0.4.9_p20060517 looks good on ppc64. 

the ebuild is masked by -*. should we add ~arch to the ebuild or just bump it
to stable when this will get public?

I added a new snapshot in portage, please test and make it stable if nothing is
wrong.

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
*  
/usr/portage/media-video/ffmpeg/files/ffmpeg-0.4.9_p20060530-amr-64bit.patch
 *   ( ffmpeg-0.4.9_p20060530-amr-64bit.patch )


ffmpeg-0.4.9_p20060302-amr-64bit.patch applies cleanly.

ops, added back.

Gave it a ~sparc, seems to work fine.

Seems to work on hppa

looks good on amd64.

Dies on ~x86.  Stable seems alright, but this one will have to be fixed as well
before I keyword it.  I'll try to figure it out, but I'm not terribly good with
x86 asm :)

i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -march=pentium4m -pipe -ggdb
-fomit-frame-pointer -fomit-frame-pointer -DHAVE_AV_CONFIG_H -I..
-I/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavutil
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE  -fPIC -DPIC -c -o
i386/snowdsp_mmx.o i386/snowdsp_mmx.c
i386/snowdsp_mmx.c: In function 

Dies on ~x86.  Stable seems alright, but this one will have to be fixed as well
before I keyword it.  I'll try to figure it out, but I'm not terribly good with
x86 asm :)

i686-pc-linux-gnu-gcc -Wall -Wno-switch -O2 -march=pentium4m -pipe -ggdb
-fomit-frame-pointer -fomit-frame-pointer -DHAVE_AV_CONFIG_H -I..
-I/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavutil
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE  -fPIC -DPIC -c -o
i386/snowdsp_mmx.o i386/snowdsp_mmx.c
i386/snowdsp_mmx.c: In function ‘ff_snow_vertical_compose97i_sse2’:
i386/snowdsp_mmx.c:461: error: PIC register ‘%ebx’ clobbered in ‘asm’
i386/snowdsp_mmx.c: In function ‘ff_snow_vertical_compose97i_mmx’:
i386/snowdsp_mmx.c:568: error: PIC register ‘%ebx’ clobbered in ‘asm’
i386/snowdsp_mmx.c: In function ‘inner_add_yblock_bw_8_obmc_16_mmx’:
i386/snowdsp_mmx.c:869: error: PIC register ‘%ebx’ clobbered in ‘asm’
make[1]: *** [i386/snowdsp_mmx.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/ffmpeg-0.4.9_p20060530/work/ffmpeg-0.4.9-p20060530-shared/libavcodec'
make: *** [lib] Error 2

!!! ERROR: media-video/ffmpeg-0.4.9_p20060530 failed.

try with -O3, if is working I'll add another check about it...

Already ~ppc'ed and also "worksforme"

(In reply to comment #26)
> try with -O3, if is working I'll add another check about it...
> 

-O3 does not help.  I get the same error.  Also seems kind of hackish to depend
on an optimization flag to make the inline asm to work.

I do have a serious problem with version 0.4.9_p20060530 on PPC64.

I'm getting an internal error:


/usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.6/../../../../powerpc64-unknown-linux-gnu/bin/ld:
BFD 2.16.1 internal error, aborting at
/var/tmp/portage/binutils-2.16.1-r2/work/binutils-2.16.1/bfd/elflink.c line
6536 in elf_link_output_extsym
/usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.6/../../../../powerpc64-unknown-linux-gnu/bin/ld:
Please report this bug.


This is already fixed in binutils versions 2.16.9x.

I just don't know how to handle this. Any advice?

Luca can you help on comment #29?

I cannot tell since I don't have access to ppc64 nor I have a crossenv ready,
I'd update binutils if the issue is there.

This still misses successful checks from alpha, x86 and ppc64.

I marked it ~ppc64 since I eventually managed to test it (and seems working
fine)

Any news from alpha, x86 and ppc64?

Any news from alpha, x86 and ppc64?

sorry, I missed the last 'ping' ...

I don't know what exactly changed, but using binutils-2.16.1-r3 just works. So
PPC64 is ready to go!

tsunam, kloeri any news on this one?

530 emerges fine on x86; and is okie to go with me.

530 is fine on Alpha. Sorry about the delay.

This one is ready for GLSA.

Luca is there anything public about this upstream?

I think most of the applications using it updated their internal copy and made
a note about it long ago.

Luca, do you have an URL or another pointer for an upstream statement?

http://www.mplayerhq.hu/design7/
http://xinehq.de/index.php/news

To name two.

By the way, xine in Gentoo uses external FFmpeg.

Thx Luca, that was too obvious :-) Opening bug.

Do we have all three issues fixed with these patches? (CVE-2005-4048,
CVE-2006-2802 and "fix for a possible buffer overflow via bad indexes in
specially-crafted AVI files")

And does this release fix any issues that was not covered by previous GLSAs?

we aren't using patches but rely on fresh snapshot with quite a number of fixes

Thx Luca, bug was already too long and I must have forgot my head today.

please correct me if i'm wrong :


- xine-lib was not affected by CVE-2005-4048 since it had been patched
(1.1.1-r3) in GLSA-200601-06. Upstream corrected it in 1.1.2.

- xine-lib was affected by CVE-2006-2802 (http issue) and it is now corrected.
(upstream 1.1.2)

- xine-lib was affected by "a fix for a possible buffer overflow via bad
indexes in specially-crafted AVI files." , corrected in upstream 1.1.2

- ffmpeg was affected by possible buffer overflows (according to the 4 patches
attached to this bug). Is there any official announcement ? Is it related to
the xine issues ?

This requires two different GLSAs, doesn't it ?

Actually ffmpeg-0.4.9_p20060530 has not been stabilized anywhere. So i guess
this bug should not be in [glsa] status. Reverting to [stable]. Again, correct
me if i'm wrong.

All the main arches have already tested it so there should be no problem.

Arches testers, can you make 20060530 as stable if it is still OK please ?

media-libs/xvid-1.1.0-r1 (dependency) and media-video/ffmpeg-0.4.9_p20060530
stable on ppc64.

So we go arch by arch then, sparc stable.

amd64 stable.

x86 stable.

ppc stable

alpha stable.

stable on hppa

Close bug? :)

We'll close the bug as soon as the GLSA is sent :)

Handling possible bundled ffmpeg code in media-tv/xdtv on bug #147335

GLSA 200609-08 and GLSA 200609-09

*** Bug 150265 has been marked as a duplicate of this bug. ***

Please modfy the 
RDEPEND x264? (=media-libs/x264-svn-20060612)
to 
RDEPEND x264? (>=media-libs/x264-svn-20060612)