168917 2007-03-01 18:10 0000 media-video/mplayer DMO buffer overflow (CVE-2007-1246) 2007-05-30 19:44:58 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED http://seclists.org/fulldisclosure/2007/Mar/0002.html B2 [glsa] jaervosz P2 normal --- 1 keith@email.arizona.edu security@gentoo.org media-video@gentoo.org keith@email.arizona.edu 2007-03-01 18:10:43 0000 There's an exploitable buffer overflow in the current version of MPlayer (v1.0rc1) which can be exploited with a maliciously crafted video file. It's hidden in the function DMO_VideoDecoder() in the file loader/dmo/DMO_VideoDecoder.c. The variable format->biSize gets its value directly from the video file, and thus can have any value up to LONG_MAX. In line 136 it is used without any further checks as the length argument to the memcpy() call, which can overflow the this->m_sVhdr->bmiHeader buffer with data directly from the video file. 117 unsigned int bihs; 118 119 bihs = (format->biSize < (int) sizeof(BITMAPINFOHEADER)) ? 120 sizeof(BITMAPINFOHEADER) : format->biSize; 121 122 this->iv.m_bh = malloc(bihs); 123 memcpy(this->iv.m_bh, format, bihs); 124 125 this->iv.m_State = STOP; 126 //this->iv.m_pFrame = 0; 127 this->iv.m_Mode = DIRECT; 128 this->iv.m_iDecpos = 0; 129 this->iv.m_iPlaypos = -1; 130 this->iv.m_fQuality = 0.0f; 131 this->iv.m_bCapable16b = true; 132 133 bihs += sizeof(VIDEOINFOHEADER) - sizeof(BITMAPINFOHEADER); 134 this->m_sVhdr = malloc(bihs); 135 memset(this->m_sVhdr, 0, bihs); 136 memcpy(&this->m_sVhdr->bmiHeader, this->iv.m_bh, this->iv.m_bh->biSize); This got fixed [1] in trunk two weeks ago. Reproducible: Didn't try beandog@gentoo.org 2007-03-01 18:49:51 0000 "This got fixed [1] in trunk two weeks ago." If anyone wants to find the patch, that'd be great. dercorny@gentoo.org 2007-03-02 08:32:44 0000 this looks like the patch: http://svn.mplayerhq.hu/mplayer/trunk/loader/dmo/DMO_VideoDecoder.c?r1=22019&r2=22204 lu_zero@gentoo.org 2007-03-02 11:27:47 0000 I'm thinking about adding a snapshot of ffmpeg and mplayer in the weekend dercorny@gentoo.org 2007-03-02 13:50:51 0000 i doubt this whole thing. line 134 allocates memory based upon the value in bihs. due to line 119 and 120, this value should be ok (actually, a bit larger than format->biSize due to line 134). i see no way how format->biSize can be larger than the allocated memory. comments? py@gentoo.org 2007-03-13 13:32:07 0000 According to http://secunia.com/advisories/24444/, this bug is now fixed in the SVN repository (CVE-2007-1246) falco@gentoo.org 2007-03-15 21:58:03 0000 Luca or video-team any news on this? beandog@gentoo.org 2007-03-16 00:42:14 0000 (In reply to comment #6) > Luca or video-team any news on this? > its a work in progress jaervosz@gentoo.org 2007-04-04 07:54:00 0000 Is it just me or is this a dupe of #170208 falco@gentoo.org 2007-04-09 18:49:41 0000 (In reply to comment #8) > Is it just me or is this a dupe of #170208 > Same origin, but mplayer is still vulnerable. Video team, is your work going well? jaervosz@gentoo.org 2007-04-18 05:51:07 0000 Media-video any news on this one? beandog@gentoo.org 2007-04-26 15:53:28 0000 Finally fixed the naming scheme, mplayer-1.0.20070321 is our security fix. jaervosz@gentoo.org 2007-04-30 12:44:24 0000 Thx Beandog. Arches please test and mark stable. Target keywords are: mplayer-1.0.20070321.ebuild:KEYWORDS="alpha amd64 hppa ia64 ppc ppc64 sparc x86 ~x86-fbsd" armin76@gentoo.org 2007-04-30 15:25:23 0000 ia64 + x86 stable kingtaco@gentoo.org 2007-04-30 15:37:51 0000 26 Apr 2007; Steve Dibb <beandog@gentoo.org> mplayer-1.0.20070321.ebuild: amd64 stable gustavoz@gentoo.org 2007-04-30 21:10:17 0000 sparc stable. corsair@gentoo.org 2007-05-01 08:39:50 0000 ppc64 stable kloeri@gentoo.org 2007-05-02 11:58:44 0000 Stable on Alpha. jer@gentoo.org 2007-05-02 15:28:39 0000 Stable for HPPA. dertobi123@gentoo.org 2007-05-03 18:38:51 0000 ppc stable falco@gentoo.org 2007-05-30 19:44:58 0000 200705-21 is out, thansk everybody