tag 361863 + patch
thanks
On Wed, Apr 19, 2006 at 06:13:55PM +0200, Daniel Kobras wrote:
> On Mon, Apr 10, 2006 at 10:12:29PM +0200, Stefan Fritsch wrote:
> > "Unspecified vulnerability in mpg123 0.59r allows user-complicit
> > attackers to trigger a segmentation fault and possibly have other
> > impacts via a certain MP3 file, as demonstrated by mpg1DoS3. NOTE:
> > this issue might be related to CVE-2004-0991, but it is not clear."
>
> Yep, thanks, I spotted it on vuln-dev already. I've investigated in the
> meantime: The crash is caused by a heap overflow in
> layer3.c::III_antialias(). The data written to the overflow region is
> taken straight from the mp3, so it's quite likely that this bug allows
> to inject arbitrary data. I have a patch that plugs the hole the hard
> way with an exit()[0], effectively turning it into a DoS. Alas, it only
> cures a symptom. The actual bug lies elsewhere, and I haven't managed
> yet to identify the exact piece of code that fails to properly verify
> the mp3 data. Anyway, just wanted to drop a note that I'm working on it.
The root cause of this bug lies in layer3.c::III_i_stereo(). A specially
crafted MPEG 2.0-type stereo frame with block type feature set to 2 in
the frame header can trigger a stack overflow in this function if it
flags all subbands to belong to the left channel. I'm not sure whether
such settings make sense for real data. In any case, the code didn't
take it into account, and as a result copied a fixed amount of data past
the end of the xr array. It is allocated on the stack in the calling
function, do_layer3(). There are plenty of other variables on the stack
before the xr array (actually called hybridIn in do_layer3()), so the
overflow cannot be exploited directly. However, it's possible to
overwrite several variable in do_layer3() from user-supplied data.
gr_info->maxb in particular is used later on as a loop boundary.
Modifying this value it is possible to overflow the same xr/hybridIn
array once more in III_antialias(), but this time the size of the
overflowing region can be arbitrarily large. To a limited extent, data
written to the overflow region can be user-controlled. Therefore, it
might be possible to exploit this bug to execute arbitrary code with
privileges of a user opening a malicious MPEG 2.0 layer3 file. The
attached patch prevents the hole by skipping the unnecessary copy of
subband data in the corner case mentioned above.
Regards,
Daniel.
Index: layer3.c
===================================================================
RCS file: /home/kobras/cvsroot/debian/mpg123/layer3.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- layer3.c 7 Sep 2004 13:48:58 -0000 1.5
+++ layer3.c 28 Apr 2006 15:02:34 -0000 1.6
@@ -1125,7 +1125,10 @@
}
else { /* ((gr_info->block_type != 2)) */
int sfb = gr_info->maxbandl;
- int is_p,idx = bi->longIdx[sfb];
+ int is_p,idx;
+ if (sfb > 21)
+ return;
+ idx = bi->longIdx[sfb];
for ( ; sfb<21; sfb++) {
int sb = bi->longDiff[sfb];
is_p = scalefac[sfb]; /* scale: 0-15 */
