Re: [Full-disclosure] CAL-20070912-1 Multiple vendor produce handling AVI file vulnerabilities
* Code Audit Labs: that's funny, the above code still can be bypassed because of incorrect check order. and example code calloc(0x1001, 0x10); it will return NULL in winxp or gligc 2.5 it will return 0x10 sizes heap in glibc 2.5(maybe prior) or win2000 sp4 This bug has been fixed in GNU libc CVS in August 2002. I've just checked version 2.3.6, and it does return NULL on overflow. There is, however, a different version of calloc that GDB sees, but this is not the real one invoked by application code. On Windows, this bug depends on the Microsoft Visual C++ run-time library. As a result, it's not completely determined by the Windows version alone. By the way, the similar operator new[] issue that has been reported in conjunction with that calloc issue: http://cert.uni-stuttgart.de/advisories/calloc.php has allegedly been fixed by Microsoft as well, by throwing std::bad_alloc. G++ and libstdc++ are still vulnerable to applications that perform unbounded allocations. Over the years, it's been debated again and again what the C++ standard says on this matter, how large the performance impact would be, and so on, but no one has created a patch (which would need to change the cross-vendor C++ ABI, too). The Ada Reference Manual does not preclude a fix, but I don't think anyone has written a patch for GNAT. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CAL-20070912-1 Multiple vendor produce handling AVI file vulnerabilities
CAL-20070912-1 Multiple vendor produce handling AVI file vulnerabilities
Code Audit Labs (http://www.vulnhunt.com) Code Audit for some popular
media player and discovered some vulnerabilities.
one heap overflow was discovered in MPlayer.
one heap overflow and one integer overflow were discovered in media
player classic(mpc) and other produces base on mpc like mympc and
StormPlayer).
Some D.o.S (raise 100% cpu ) were discovred in KMPlayer.
By tricking a user into opening a specially crafted media file,
an attacker who exploit heap overflow in MPlayer or media player classic
could potential execute arbitrary code with the user's privileges.
Original LINK:
==
http://www.vulnhunt.com/advisories/CAL-20070912-1_Multiple_vendor_produce_handling_AVI_file_vulnerabilities.txt
Affected Product
=
1 MPlayer 1.0rc1 and prior (we tested version 20070729)
2 media player classic v6.4.9.0 and prior; and other produces base on it.
( mympc 1.0.0.1 and StormPlayer 1.0.4)
3 KMPlayer v2.9.3.1210 and prior
Technical Description
=
those vulnerabilities are discoered via playing with AVI
1) indx truck size
2) wLongsPerEntry
3) nEntriesInuse
Olny build 5 testcases
test case 1 (new_avihead_poc1.avi)
--
69 6E 64 78 FF FF FF FF 01 00 64 73 20 00 00 10
indx truck size 0x
wLongsPerEntry 0x0001
BIndexSubType is 0x64
bIndexType is 0x73
nEntriesInuse is 0x1020
test case 2 (new_avihead_poc2.avi)
--
69 6E 64 78 00 FF FF FF FF FF 64 73 FF FF FF FF
indx truck size 0xff00
wLongsPerEntry 0x
BIndexSubType is 0x64
bIndexType is 0x73
nEntriesInuse is 0x
test case 3 (new_avihead_poc3.avi)
--
69 6E 64 78 00 FF FF FF 01 11 64 73 20 00 00 10
indx truck size 0xff00
wLongsPerEntry 0x0001
BIndexSubType is 0x64
bIndexType is 0x73
nEntriesInuse is 0x1020
test case 4 (new_avihead_poc4.avi)
--
69 6E 64 78 00 FF 00 00 01 00 64 73 20 00 00 10
indx truck size 0xff00
wLongsPerEntry 0x0001
BIndexSubType is 0x64
bIndexType is 0x73
nEntriesInuse is 0x1020
test case 5 (new_avihead_poc5.avi)
--
69 6E 64 78 00 FF 00 00 04 00 64 73 10 00 00 40
indx truck size 0xff00
wLongsPerEntry 0x0004
BIndexSubType is 0x64
bIndexType is 0x73
nEntriesInuse is 0x4010
TEST RESULT
+-+---+---+---+---+--+
| produce | testcase1 | testcase2 | testcase3 | testcase4 |testcase5 |
+-+---+---+---+---+--+
| wmp | ok | ok | ok | ok | ok |
+-+---+---+---+---+--+
| mplayer | ok | ok | HO/CRASH | ok | ok |
+-+---+---+---+---+--+
| mpc | HO | HO | HO | ok | ok |
+-+---+---+---+---+--+
|KMPlayer | RAISE CPU | RAISE CPU | RAISE CPU | ok | ok |
+-+---+---+---+---+--+
| mympc | HO | HO | HO | ok | ok |
+-+---+---+---+---+--+
|StormPlay| HO | HO | HO | ok | ok |
+-+---+---+---+---+--+
| xplayer | ok | ok | ok | ok | ok |
+-+---+---+---+---+--+
LITTLE ANALYSIS
===
MPlayer svn 20070729 (last version)
1:new_mplayer_avihead_poc3.avi null pointer in winxp or glibc 2.5(depend
on compile option).
if glibc 2.5(maybe prior) or win2000 sp4 ,it will be heap overflow.
vulnerability code in libmpdemux/aviheader.c:
232 print_avisuperindex_chunk(s,MSGL_V);
233
234 if( ((chunksize/4)/s-wLongsPerEntry) s-nEntriesInUse){
235 mp_msg (MSGT_HEADER, MSGL_WARN, Broken super index
chunk\n);
236 s-nEntriesInUse = (chunksize/4)/s-wLongsPerEntry;
237 }
238
239 // Check and fix this useless crap
240 if(s-wLongsPerEntry != sizeof (avisuperindex_entry)/4) {
241 mp_msg (MSGT_HEADER, MSGL_WARN, Broken super index
chunk size: %u\n,s-wLongsPerEntry);
242 s-wLongsPerEntry = sizeof(avisuperindex_entry)/4;
243 }
244 s-aIndex = calloc(s-nEntriesInUse, sizeof
(avisuperindex_entry));
245 s-stdidx = calloc(s-nEntriesInUse, sizeof
(avistdindex_chunk));
246
247 // now the real index of indices
248 for (i=0; is-nEntriesInUse; i++) {
249 chunksize-=16;
that's funny, the above code still can be bypassed because of
incorrect check order.
