[MPlayer-users] [xfocus-SD-060329]MPlayer: Multiple integer overflows

Ivan Kalvachev ikalvachev at gmail.com
Fri Mar 31 00:48:32 CEST 2006


I think that the first bug is not exploitable.

> [1]in libmpdemux/asfheader.c
> - -----------------------------------
>     218           asf_scrambling_h=buffer[0];
>     219           asf_scrambling_w=(buffer[2]<<8)|buffer[1];
>     220           asf_scrambling_b=(buffer[4]<<8)|buffer[3];
>     221           asf_scrambling_w/=asf_scrambling_b;
> char convert to int ,int value would be negative number.
> this lead to  asf_descrambling() heap-based buffer overflow.

the trick is that these variables are only used in demux_asf, with
protection clause:

@@123
 if(asf_scrambling_h>1 && asf_scrambling_w>1)
  asf_descrambling(&ds->asf_packet->buffer,ds->asf_packet->len);
@@

However indeed asd_scrambling_b is not checked and still could be negative.
Here comes the second lucky shot:

@@44
  while(len-i>=asf_scrambling_h*asf_scrambling_w*asf_scrambling_b)
@@

note that i=0 and len >0, thus the other part of the equation must be
positive.  Unfortunately only asf_scrambling_b could be negative, so
this while() will never execute its body, where memcpy is performed
and heap corruption could occur.

The variants where the triple multiplications overflow are quite
troubled because of the division (that even you placed in the
advisory) :
>     221           asf_scrambling_w/=asf_scrambling_b;
this means that _w*_b cannot get bigger than 16 meaning bits (the
maximum size of _w) so with _h using 8 bits we are in quite big safe
zone (16+8=24 ;)

Anyway, i may miss something, so if you have values that could trigger
some weird behaviour i would be happy if you to send them to me.




More information about the MPlayer-users mailing list