Also posted at: http://www.videolan.org/security/sa1004.html ----8<--------8<--------8<--------8<--------8<--------8<--------8<---- VideoLAN Security Advisory 1004 Summary : Insufficient input validation in VLC TagLib plugin Date : August 2011 Affected versions : VLC media player versions 1.1.2 down to 0.9.0 ID : VideoLAN-SA-1004 CVE reference : N/A Details VLC fails to perform sufficient input validation when trying to extract some meta-informations about input media through ID3v2 tags. In the failure case, VLC attempt dereference an invalid memory address, and a crash will ensure. Impact In the failure case, VLC will dereference a memory address within the first page of its process virtual memory. In normal conditions, and on most operating systems, this will result in a segmentation fault (a general protection fault on Windows), and the process will terminate abruptly. In most usage scenarii, this will only cause user annoyance. Threat mitigation Exploitation of this issue requires the user to include a file in its playlist or to attempt to open it. Workarounds The user should refrain from opening files from untrusted third parties or accessing untrusted remote sites (or disable the VLC browser plugins), until the patch is applied. Solution VLC media player 1.1.3 [will address] this issue. Patches for VLC media player 1.1.x and 1.0.x are available from the corresponding official VLC source code repositories. Credits This vulnerability was reported by FortiGuard Labs. References The VideoLAN project http://www.videolan.org/ FortiGuard Labs http://www.fortinet.com/ Patch for VLC 1.1.2, 1.1.1, 1.1.0 commit 24918843e57c7962e28fcb01845adce82bed6516 Patch for VLC 1.0.6 commit 22a22e356c9d93993086810b2e25b59b55925b3a ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
1.1.3 is in tree with fixes
Arches, please test and mark stable: =media-video/vlc-1.1.4 Target keywords : "alpha amd64 ppc ppc64 sparc x86"
(In reply to comment #2) > Arches, please test and mark stable: > =media-video/vlc-1.1.4 > Target keywords : "alpha amd64 ppc ppc64 sparc x86" This drags too many dependencies. I suggest we bump the ebuild to vlc-1.1.4-r1, and for vlc-1.1.4 drop the support for USE="vaapi".
Or provide a full list of the packages that should go stable
(In reply to comment #4) > Or provide a full list of the packages that should go stable > We shouldn't be pulling in new packages in a security update. As far as we are concerned, we should have stabled 1.1.3, but that disappeared from the tree quite quickly again. If that doesn't have the new dependencies, maybe we could readd that. Alexis, please advise.
(In reply to comment #5) > (In reply to comment #4) > > Or provide a full list of the packages that should go stable > > > > We shouldn't be pulling in new packages in a security update. We shouldn't be crippling packages of their features either. > As far as we are concerned, we should have stabled 1.1.3, but that disappeared > from the tree quite quickly again. If that doesn't have the new dependencies, > maybe we could readd that. Alexis, please advise. Check the attic, ebuilds are exactly the same. IMHO it's better to _try_ to stabilize it as is but it may indeed be difficult; please provide a list of what needs to go stable so that we can see if its doable. vaapi support has been in our ebuilds since 1.1.0; upstream advertises hardware acceleration as a cool feature for vlc 1.1; it would be a shame not to provide it to our stable users only because we are lazy to move forward.
On x86, the list is the following (I tried to be conservative): =media-video/vlc-1.1.4 =media-libs/x264-0.0.20100605 =x11-libs/libva-0.31.0_p13 =media-video/ffmpeg-0.5_p22846 Is this ok? Especially ffmpeg may be a problem...or should we try 0.6.0?
> Is this ok? Especially ffmpeg may be a problem...or should we try 0.6.0? 0.5.0 is having issues in testing, 0.6.0 at least passes the compile test without problems. Will build all reverse dependencies, if you know about any runtime problems, please tell, so we can fix that.
Build failures for ffmepg 0.6.0 which can be resolved by stabilising newer versions: vdr backlite No fixed version available, but some other solution (requires several bugs to be fixed, plus asterisk stabilisation): openh323
(In reply to comment #7) > On x86, the list is the following (I tried to be conservative): > > =media-video/vlc-1.1.4 > =media-libs/x264-0.0.20100605 dont forget the matching x264-encoder > =x11-libs/libva-0.31.0_p13 otherwise these 3 should be fine > =media-video/ffmpeg-0.5_p22846 > > Is this ok? Especially ffmpeg may be a problem...or should we try 0.6.0? better go with ffmpeg 0.6 indeed (In reply to comment #9) > Build failures for ffmepg 0.6.0 which can be resolved by stabilising newer > versions: > vdr > backlite I guess it's safe to ask the maintainers to stabilize 'em > No fixed version available, but some other solution (requires several bugs to > be fixed, plus asterisk stabilisation): > openh323 if it's a regression from current stable to 0.6 it's probably trivial to fix. if there is no bug, please open one and cc me, i'll fix it asap and thanks for doing the tinderbox check for ffmpeg 0.6 (I had asked diego but he does not have a stable tinderbox :( ) only "bug" in 0.6 is bug #329921 so far, but I prefer to stick with a release for stable and get a new snapshot afterwards bug #324255 might shed some light on what needs to be checked also, x264 revdeps should be checked too but this is likely to be fine
openh323 is not an issue, stabilisation requests filed, I call for runtime testing on the Planet and via identi.ca. I forgot transcode, which needs a newer version, too. So, packages to be stabilised for this are: =media-video/vlc-1.1.4 =media-libs/x264-0.0.20100605 =media-video/x264-encoder-0.0.20100605 =x11-libs/libva-0.31.0_p13 =media-video/ffmpeg-0.6
x11-libs/libva needs x11-libs/vdpau-video if built with VIDEO_CARDS="nvidia".
CVE-2010-2937 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-2937): The ReadMetaFromId3v2 function in taglib.cpp in the TagLib plugin in VideoLAN VLC media player 0.9.0 through 1.1.2 does not properly process ID3v2 tags, which allows remote attackers to cause a denial of service (application crash) via a crafted media file.
Stable on alpha (we skipped x11-libs/libva, though, it isn't even keyworded; but we took libmodplug along (cf. bug 333431).
stable x86
To not delay this any further I just ignored that outstanding bug...I also removed Intel support for x11-libs/libva (hopefully without breaking anything), because that needs newer libdrm and intel-drivers which are not ready for stabilisation according to remi and scarabeus. Will stay on this bug for any complaints and stuff.
sparc stable
amd64 ( should be ) done
Adding remaining target arches for =media-video/ffmpeg-0.6.
ppc done
Stable for HPPA.
ppc64 done
arm stable (ffmpeg)
GLSA with bug 279340.
This issue was resolved and addressed in GLSA 201411-01 at http://security.gentoo.org/glsa/glsa-201411-01.xml by GLSA coordinator Sean Amoss (ackle).
