Compromising pictures of Microsoft Internet Explorer!

From: Michal Zalewski (lcamtuf_at_dione.ids.pl)
Date: 07/15/05

  • Next message: Steve Kemp: "Re: several vulnerabilities present in Belkin wireless routers"
    Date: Fri, 15 Jul 2005 17:32:35 +0200 (CEST)
    To: bugtraq@securityfocus.com
    
    
    

    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@felinemenace 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 message: Steve Kemp: "Re: several vulnerabilities present in Belkin wireless routers"

    Relevant Pages

    • [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!
      ... to report on a casual 30-minute experiment I've conducted of recent. ... You might remember the 'mangleme' affair, where various browsers were ... MSIE performed admirably compared to other browsers (although ... unless code execution path can be affected later on. ...
      (Full-Disclosure)
    • Re: [Full-Disclosure] Web browsers - a mini-farce
      ... report it to them and to FD or other lists. ... Microsoft did something others couldn't be bothered to. ... I specifically stated that this does *NOT* prove that MSIE is safer to ... browsers, suggesting that much of it may turn to be just a result of the ...
      (Full-Disclosure)
    • Re: Javascript Best Practices Document v1.0
      ... Especially when there are hundreds of links on a page, having each one contain a useless href is pointless, when the user is known to have javascript enabled. ... If your goal is to support modern browsers, then why do you need to detect the support for getElementById? ... You gave examples and a how-to to support MSIE 4.x in your 1st draft of your document and I still see that in your fallback recommendation for that unique particular browser version. ...
      (comp.lang.javascript)
    • Re: Connection Failure Error
      ... > I have both MSIE 6 and Mozilla Forefox as my browsers. ... > Had Adblock extension for Firefox 1.04, ... MSIE 6.0.2800.1106 w/ SP1 and a host of Qnnnnnn ... and I can't find anything about popup blocking. ...
      (microsoft.public.windows.inetexplorer.ie6.browser)
    • Re: Connection Failure Error
      ... >> I have both MSIE 6 and Mozilla Forefox as my browsers. ... > popup blocker. ... and I can't find anything about popup blocking. ...
      (microsoft.public.windows.inetexplorer.ie6.browser)