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 attachment 86870 [details, diff] ffmpeg1.diff
Created attachment 86871 [details, diff] ffmpeg2.diff
Created attachment 86872 [details, diff] ffmpeg3.diff
Created attachment 86873 [details, diff] 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?
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)
