Drew Yao and Nico Golde reported (public): Name: CVE-2008-1489 Integer overflow in the MP4_ReadBox_rdrf function in libmp4.c for VLC 0.8.6e allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted MP4 RDRF box that triggers a heap-based buffer overflow, a different vulnerability than CVE-2008-0984. Fix: http://trac.videolan.org/vlc/changeset/09572892df7e72c0d4e598c0b5e076cf330d8b0a Drew Yao also reported these, which are SEMI-PUBLIC: * Integer overflow in MP4 demuxer MP4_ReadBox_padb http://trac.videolan.org/vlc/changeset/3a6282755277ba9321d405c635e50da935d258a6 http://trac.videolan.org/vlc/changeset/edca13e259472872fdfd456cf3ef4a21d1262c11 * Integer overflow in Real demuxer ReadCodecSpecificData() http://trac.videolan.org/vlc/changeset/783ab03c7bd8ddedcd3dc5bad18efc70a4c57aaa * Integer overflow in Cinepak codec http://trac.videolan.org/vlc/changeset/18eb4fd5a75b6429d1d7058a8967696be701a00b
I'm opening this bug restricted. Since the patches are public, i'm rating it SEMI-PUBLIC. I enquired with Drew Yao about the publicity status. IMHO we can wait until the xine issues from bug 214270 are fixed, and stable a big bump. Alexis, what do you think?
(In reply to comment #1) > I'm opening this bug restricted. Since the patches are public, i'm rating it > SEMI-PUBLIC. I enquired with Drew Yao about the publicity status. hmm damn; I had completely forgot about the mp4's ones for -r1. The other ones have been pushed only very recently. > IMHO we can wait until the xine issues from bug 214270 are fixed, and stable a > big bump. Alexis, what do you think? What I would prefer is waiting for 0.8.6f to be sure we do not forget anything, but as we have the patches, just ping me when you think its time.
(In reply to comment #0) > * Integer overflow in Cinepak codec > http://trac.videolan.org/vlc/changeset/18eb4fd5a75b6429d1d7058a8967696be701a00b if we choose to patch we mustn't forget: cinepak: do not access arrays beyond allocated size 0.8.6-bugfix http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=cf489d7bff3c1b36b2d5501ecf21129c78104d98
I heard the release should come out within a week, so we could wait.
Public, as agreed by both Drew and VLC upstream.
0.8.6f is out, I wonder how many of these changes were actually merged (judging from the changelog, not all) and what the xine bug 214270 status is.
(In reply to comment #6) > 0.8.6f is out, I wonder how many of these changes were actually merged bumped; all the fixes should be there: Changes between 0.8.6e and 0.8.6f: ---------------------------------- Security updates: * Really fixed subtitle buffer overflow (CVE-2007-6681) * Fixed Real RTSP code execution problem (CVE-2008-0073) * Fixed MP4 integer overflows (CVE-2008-1489) * Fixed cinepak integer overflow Various bugfixes: * The Mozilla plugin registers a usable range of MIME-types on Mac OS X * Improved VLC's video output behavior on multi-screen setups running Mac OS X * Fixed crashes in H264 packetizer * Close MMS access on network timeout * Fix some problems with AAC decoder & packetizer
Arches, please test and mark stable: =media-video/vlc-0.8.6f Target keywords : "alpha amd64 ppc release sparc x86"
Stable on alpha.
amd64/x86 stable
sparc stable
ppc stable
Fixed in release snapshot.
CVE-2008-1768 covers the last four links of the initial posting (all integer overflows except for CVE-2008-1489). CVE-2008-1769 covers the issue from comment 3.
GLSA 200804-25
