lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Pine.LNX.4.58.0507151737090.15236@dione> Date: Fri Jul 15 16:38:27 2005 From: lcamtuf at dione.ids.pl (Michal Zalewski) Subject: Compromising pictures of Microsoft Internet Explorer! Synopsis: --------- Well, not really. Instead, at the risk of boring you to death, I'd like to report on a casual 30-minute experiment I've conducted of recent. 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. Discussion: ----------- 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 embarassment when ned@...inemenace found the infamous IFRAME bug that way): http://lcamtuf.coredump.cx/mangleme/gallery/ Of recent, I decided to try something completely different and radically new, without having to do any actual work. I 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. I 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 my old afx utility. Surprisingly, it is MSIE and its proprietary JPEG decoder (apparently not shared with other Windows components?) that performed embarassingly poor this time. Results below. 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). My 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. I didn't examine the renderer to see what went wrong; I see unbounded, user-dependent memory accesses, and that spells trouble. Vendor notification: -------------------- It is my experience that reporting and discussing security problems with Microsoft is a needlessly lengthy process that puts too much burden and effort on the researcher's end, especially if you just have a crash case, not a working exploit; hence, they did not get an advance notice. Bonus (OT) ---------- Since piggyback request smuggling and fooling proxies and filters is a popular new pastime, some of you might find it entertaining to have a look at how various applications differ in handling duplicate instances of HTTP/SMTP message/NNTP headers that are, in common perception, "supposed to" occur only once. -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2005-07-14 00:29 -- http://lcamtuf.coredump.cx/silence/ -------------- next part -------------- #!/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
Powered by blists - more mailing lists