Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 332361 (CVE-2010-2937) - <media-video/vlc-1.1.4: Insufficient input validation in VLC (CVE-2010-2937)
Summary: <media-video/vlc-1.1.4: Insufficient input validation in VLC (CVE-2010-2937)
Status: RESOLVED FIXED
Alias: CVE-2010-2937
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://www.videolan.org/security/sa10...
Whiteboard: A3 [glsa]
Keywords:
Depends on: 329921 335426 335428 335429
Blocks: 339102
  Show dependency tree
 
Reported: 2010-08-11 20:27 UTC by Tim Sammut (RETIRED)
Modified: 2014-11-05 22:07 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Sammut (RETIRED) gentoo-dev 2010-08-11 20:27:48 UTC
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<----
Comment 1 Alexis Ballier gentoo-dev 2010-08-19 09:50:38 UTC
1.1.3 is in tree with fixes
Comment 2 Tim Sammut (RETIRED) gentoo-dev 2010-08-28 20:57:00 UTC
Arches, please test and mark stable:
=media-video/vlc-1.1.4
Target keywords : "alpha amd64 ppc ppc64 sparc x86"

Comment 3 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2010-08-28 23:28:43 UTC
(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".
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2010-08-29 07:53:57 UTC
Or provide a full list of the packages that should go stable
Comment 5 Alex Legler (RETIRED) archtester gentoo-dev Security 2010-08-29 09:11:54 UTC
(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.
Comment 6 Alexis Ballier gentoo-dev 2010-08-29 18:21:06 UTC
(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.
Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2010-08-31 07:40:23 UTC
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?
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2010-08-31 10:07:55 UTC
> 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.
Comment 9 Christian Faulhammer (RETIRED) gentoo-dev 2010-08-31 13:00:17 UTC
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
Comment 10 Alexis Ballier gentoo-dev 2010-08-31 14:04:47 UTC
(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
Comment 11 Christian Faulhammer (RETIRED) gentoo-dev 2010-08-31 15:20:11 UTC
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
Comment 12 Ewoud Kohl van Wijngaarden 2010-08-31 20:26:12 UTC
x11-libs/libva needs x11-libs/vdpau-video if built with VIDEO_CARDS="nvidia".
Comment 13 Stefan Behte (RETIRED) gentoo-dev Security 2010-09-03 22:30:52 UTC
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.

Comment 14 Tobias Klausmann (RETIRED) gentoo-dev 2010-09-13 15:45:12 UTC
Stable on alpha (we skipped x11-libs/libva, though, it isn't even keyworded; but we took libmodplug along (cf. bug 333431).
Comment 15 Christian Faulhammer (RETIRED) gentoo-dev 2010-09-17 09:47:44 UTC
stable x86
Comment 16 Christian Faulhammer (RETIRED) gentoo-dev 2010-09-17 09:52:36 UTC
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.
Comment 17 Raúl Porcel (RETIRED) gentoo-dev 2010-09-24 16:46:25 UTC
sparc stable
Comment 18 Markos Chandras (RETIRED) gentoo-dev 2010-09-24 20:43:43 UTC
amd64 ( should be ) done
Comment 19 Jeroen Roovers (RETIRED) gentoo-dev 2010-10-08 17:22:56 UTC
Adding remaining target arches for =media-video/ffmpeg-0.6.
Comment 20 Brent Baude (RETIRED) gentoo-dev 2010-10-08 19:46:38 UTC
ppc done
Comment 21 Jeroen Roovers (RETIRED) gentoo-dev 2010-10-11 18:52:46 UTC
Stable for HPPA.
Comment 22 Mark Loeser (RETIRED) gentoo-dev 2010-10-25 18:39:06 UTC
ppc64 done
Comment 23 Markus Meier gentoo-dev 2010-11-03 18:01:38 UTC
arm stable (ffmpeg)
Comment 24 Raúl Porcel (RETIRED) gentoo-dev 2010-11-14 19:11:36 UTC
sparc stable
Comment 25 Tim Sammut (RETIRED) gentoo-dev 2010-11-14 21:40:41 UTC
GLSA with bug 279340.
Comment 26 GLSAMaker/CVETool Bot gentoo-dev 2014-11-05 22:07:55 UTC
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).