[NT] Internet Explorer's Image Decoder Multiple Vulnerabilities
From: SecuriTeam (support_at_securiteam.com)
To: firstname.lastname@example.org Date: 18 Jul 2005 17:43:52 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
- - - - - - - - -
Internet Explorer's Image Decoder Multiple Vulnerabilities
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.
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):
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.
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.
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.
<http://lcamtuf.coredump.cx/crash/mov_fencepost.jpg> 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
<http://lcamtuf.coredump.cx/crash/cmp_fencepost.jpg> 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.
<http://lcamtuf.coredump.cx/crash/oom_dos.jpg> oom_dos.jpg - usually
causes a OOM crash. Less interesting, unless you like to punish people who
borrow your pictures for their blogs.
<http://lcamtuf.coredump.cx/crash/random.jpg> 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.
echo "Content-Type: text/html"
rm -f timg-* AFX.log
<META HTTP-EQUIV="Refresh" content="0;URL=/">
for i in img/*; do
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>"
The information has been provided by <mailto:email@example.com> Michal
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.