Internet Explorer's Image Decoder Multiple Vulnerabilities Summary
Michal Zalewski reporting his findings on testing MSIE for image decompression and parsing flaws. "This experiment resulted in identifying a potential remote code execution path in Microsoft Internet Explorer, plus some other bugs, and should be a good starting point for further testing of other browsers or similar programs."
Multiple vulnerabilities discovered in Microsoft Internet Explorer image decompression and parsing routines.
Credit:
The information has been provided by Michal Zalewski.
Details
You might remember the 'mangleme' affair, where various browsers were subjected by yours truly to a trivially constructed malformed HTML crash-course - all that in order to find exploitable input handling flaws. Back then, MSIE performed admirably compared to other browsers (although did not escape some embarrassment when ned@felinemenace found the infamous IFRAME bug that way):
http://lcamtuf.coredump.cx/mangleme/gallery/
Of recent, the author decided to try something completely different and radically new, without having to do any actual work. He used the same META REFRESH auto-test framework to check for image decompression and parsing flaws (JPEG, GIF, PNG), as opposed to making fun of HTML renderers.
Author used a simple index.cgi script (attached, though hardly noteworthy) to dynamically generate a page that references ten just as dynamically created images. These images were prepared by running a test set of pictures (some regular ones, and several pathological cases created with ImageMagick) through a slightly modified version of Michal's old AFX utility. Surprisingly, it is MSIE and its proprietary JPEG decoder (apparently not shared with other Windows components) that performed embarrassingly poor this time.
Vulnerability examples:
NOTE #1: As with mangleme, this list of problems is most certainly NOT exhaustive, and performing longer tests or improving the technique would most likely result in additional findings.
Several MSIE crash sample files from that 30-minute run are available at:
http://lcamtuf.coredump.cx/crash/
Note that these may produce different results depending on program versions, plugins and configuration. Tested with WinXP Pro PL 2600.xpsp2.050301-1526 SP1, MSIE PL 6.0.2800.1106, up-to-date.
mov_fencepost.jpg - on most platforms, causes a crash due to mov destination fencepost error after going past allocated memory, or after accessing a bogus address such as 0x27272727. The destination address appears to be controllable (i.e. changing the file or displaying other data before or along with this image alters it). Author's bets are that this is exploitable for remote execution.
cmp_fencepost.jpg - here, causes a crash due to a very similar cmp fencepost (no write). Not necessarily exploitable for remote code execution, unless code execution path can be affected later on.
oom_dos.jpg - usually causes a OOM crash. Less interesting, unless you like to punish people who borrow your pictures for their blogs.
random.jpg - causes mov fencepost of CPU consumption + crash. Didn't investigate in much detail.
NOTE #2: MSIE comes with no sources, and reverse engineering is naughty. Author didn't examine the renderer to see what went wrong; He saw unbounded, user-dependent memory accesses, and that spells trouble.
Script:
#!/bin/bash
echo "Content-Type: text/html"
echo
ID="timg-$$-$RANDOM-$RANDOM"
rm -f timg-* AFX.log
cat <<_EOF_
<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" content="0;URL=/">
</HEAD>
<BODY>
_EOF_
CNT=0
for i in img/*; do
CNT="$[CNT+1]"
FNAM="$ID-$CNT"
EXT=`echo $i | cut -d. -f2`
./afx-loc -p 1 -i 100 -m RANDOM -s 60000 <$i 2>$FNAM.$EXT >>AFX.log
echo "Test $CNT - <IMG SRC=\"$FNAM.$EXT\"><BR>"
done
推荐
评论(0条)
