Bug 168917 - media-video/mplayer DMO buffer overflow (CVE-2007-1246)
|
Bug#:
168917
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: keith@email.arizona.edu
|
|
Component: Vulnerabilities
|
|
|
URL:
http://seclists.org/fulldisclosure/2007/Mar/0002.html
|
|
Summary: media-video/mplayer DMO buffer overflow (CVE-2007-1246)
|
|
Keywords:
|
|
Status Whiteboard: B2 [glsa] jaervosz
|
|
Opened: 2007-03-01 18:10 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
"This got fixed [1] in trunk two weeks ago."
If anyone wants to find the patch, that'd be great.
I'm thinking about adding a snapshot of ffmpeg and mplayer in the weekend
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?
Luca or video-team any news on this?
(In reply to comment #6)
> Luca or video-team any news on this?
>
its a work in progress
Is it just me or is this a dupe of #170208
(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?
Media-video any news on this one?
Finally fixed the naming scheme, mplayer-1.0.20070321 is our security fix.
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"
200705-21 is out, thansk everybody
