Bugzilla Bug 231831

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