CVE-2008-3162 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3162): Stack-based buffer overflow in the str_read_packet function in libavformat/psxstr.c in FFmpeg before r13993 allows remote attackers to cause a denial of service (application crash) or execute arbitrary code via a crafted STR file that interleaves audio and video sectors.
Created attachment 160414 [details, diff] ffmpeg-0.4.9_p20070616-CVE-2008-3162.patch
Still to check, haven't gotten these compiled yet: ./blender-2.42a.tar.gz.1154010523.INDEX:File-00815-name: blender-2.42a/extern/ffmpeg/libavformat/psxstr.c ./blender-2.43.tar.gz.1171586190.INDEX:File-00750-name: blender-2.43/extern/ffmpeg/libavformat/psxstr.c ./blender-2.45.tar.gz.1190381171.INDEX:File-02781-name: blender-2.45/extern/ffmpeg/libavformat/psxstr.c ./gephex-0.4.3b.tar.bz2.1118080542.INDEX:File-00619-name: gephex-0.4.3/contrib/ffmpeg/libavformat/psxstr.c ./xdtv-2.4.0.tar.gz.1172098008.INDEX:File-00728-name: xdtv-2.4.0/libavformat/psxstr.c
This is gonna be a pain: we haven't completely migrated stable to swscaler, thus cannot stabilise a new version that easily. The main blocker was vlc, 0.9 is going better but not stable material yet imho. Moreover, some ebuilds do has_version checks to decide if ffmepg has swscaler or not, so bumping to a -r3 will break those checks :/
(In reply to comment #2) > ./xdtv-2.4.0.tar.gz.1172098008.INDEX:File-00728-name: > xdtv-2.4.0/libavformat/psxstr.c Our ebuild uses external ffmpeg.
Another pita: anything that depends on >=media-video/ffmpeg-0.4.9_p20070616-r1 means they need swscaler, so their deps will have to be adjusted if we choose to do a -r3 wihtout swscaler. If we choose to use swscaler, which will mean pushing way too much ~arch packages in stable, we have to keep it mind that it breaks ABI without a soname bump... Another option is to use Diego's patch: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048109.html http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048778.html with all the complications that may arise...
As I suggested in https://bugs.gentoo.org/show_bug.cgi?id=231814#c5 I think we should introduce a swscaler useflag (I'm actually using that already in my ffmpeg svn ebuild in berkano overlay).
(In reply to comment #6) > As I suggested in https://bugs.gentoo.org/show_bug.cgi?id=231814#c5 I think we > should introduce a swscaler useflag (I'm actually using that already in my > ffmpeg svn ebuild in berkano overlay). As I told you on the other bug, switching swscaler on and off breaks abi without bumping the .so number. You do what you want in your overlay but such breakage is clearly a no go for the tree. I was thinking about adding a -r3 and bumping the deps of packages needing swscaler to 20080326 (or copy -r2 to r4 and adjust the deps like that). Some packages may not work with 20080326, but as they're in ~arch they must have a fixed version against this ffmpeg version, so these versions can be punted.
For feature additions in an -r version, you might want to consider increasing the revision number even more (like -r10 or -r20). Then you can easily revbump the stable, and test the new feature in ~arch without this conflict. If you go through the hassle of this mass-edit, you should consider this.
ok, -r3 is -r0 with the patch; all the reverse deps should be fixed now. (note that vlc 0.8.6i has to go stable on amd64 first). -r20 is -r2 with the patch. I suppose that at the time swscaler was introduced in the tree nobody expected it to break like that, therefore we haven't been very careful and now have to pay for the consequences :/ The way to go is to migrate everything in stable to swscaler asap... but I was already telling that one year ago...
Arches, please test and mark stable: =media-video/ffmpeg-0.4.9_p20070616-r3 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
ppc64 stable
Stable for HPPA.
sparc stable
amd64/x86 stable
ppc stable
alpha/arm/ia64 stable
GLSA request filed.
for the record, I removed the USE ffmpeg from media-video/gephex because it was causing compilation failures anyway.. silly bundled ffmpeg.. so it's not a prob for security anymore.
GLSA 200903-33
