[NT] Internet Explorer's Image Decoder Multiple Vulnerabilities

From: SecuriTeam (support_at_securiteam.com)
Date: 07/18/05

  • Next message: SecuriTeam: "[TOOL] BlueTest - Bluetooth Scanner"
    To: list@securiteam.com
    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.

    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/> 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.

     <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

    cat <<_EOF_
    <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:lcamtuf@dione.ids.pl> 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: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.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.

  • Next message: SecuriTeam: "[TOOL] BlueTest - Bluetooth Scanner"