Likes Likes:  0
Resultaten 1 tot 4 van de 4
Geen
  1. #1
    Michal Zalewski
    Compromising pictures of Microsoft Internet Explorer!
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Compromising pictures of Microsoft Internet Explorer!

    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.
    Send mail to mime@docserver.cac.washington.edu for more info.

    ---1009447796-1606422298-1121296252=:15236
    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    Content-ID: <Pine.LNX.4.58.0507140110561.15236@dione>

    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/
    ---1009447796-1606422298-1121296252=:15236
    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="index.cgi"
    Content-Transfer-Encoding: BASE64
    Content-ID: <Pine.LNX.4.58.0507140110520.15236@dione>
    Content-Description:
    Content-Disposition: ATTACHMENT; FILENAME="index.cgi"

    IyEvYmluL2Jhc2gNCg0KZWNobyAiQ29udGVudC1UeXBlOiB0ZX h0L2h0bWwi
    DQplY2hvDQoNCklEPSJ0aW1nLSQkLSRSQU5ET00tJFJBTkRPTS INCg0Kcm0g
    LWYgdGltZy0qIEFGWC5sb2cNCg0KY2F0IDw8X0VPRl8NCjxIVE 1MPg0KPEhF
    QUQ+DQo8TUVUQSBIVFRQLUVRVUlWPSJSZWZyZXNoIiBjb250ZW 50PSIwO1VS
    TD0vIj4NCjwvSEVBRD4NCjxCT0RZPg0KX0VPRl8NCg0KQ05UPT ANCg0KZm9y
    IGkgaW4gaW1nLyo7IGRvDQogIENOVD0iJFtDTlQrMV0iDQogIE ZOQU09IiRJ
    RC0kQ05UIg0KICBFWFQ9YGVjaG8gJGkgfCBjdXQgLWQuIC1mMm ANCiAgLi9h
    ZngtbG9jIC1wIDEgLWkgMTAwIC1tIFJBTkRPTSAtcyA2MDAwMC A8JGkgMj4k
    Rk5BTS4kRVhUID4+QUZYLmxvZw0KICBlY2hvICJUZXN0ICRDTl QgLSA8SU1H
    IFNSQz1cIiRGTkFNLiRFWFRcIj48QlI+Ig0KZG9uZQ0KDQo=

    ---1009447796-1606422298-1121296252=:15236--

  2. #2
    Steve Kemp
    Compromising pictures of Microsoft Internet Explorer!
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Compromising pictures of Microsoft Internet Explorer!

    On Fri, Jul 15, 2005 at 05:32:35PM +0200, Michal Zalewski wrote:

    > 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 also did this back in May:

    http://blog.steve.org.uk/index.php/a...image-testing/

    Although my "malformed" images were purposely simplistic to
    make analysis simpler.

    Steve
    --


  3. #3
    Stefan Kelm
    Compromising pictures of Microsoft Internet Explorer!
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Compromising pictures of Microsoft Internet Explorer!

    > random.jpg - causes mov fencepost of CPU consumption + crash. Didn't
    > investigate in much detail.


    As for Opera 8.01 (W2K, SP4) this image doesn't crash Opera
    but it leads to 100% cpu usage for a few minutes. The other
    images work fine.

    Cheers,

    Stefan.
    -------------------------------------------------------
    Stefan Kelm
    Security Consultant

    Secorvo Security Consulting GmbH
    Ettlinger Stra=DFe 12-14, D-76137 Karlsruhe

    Tel. +49 721 255171-304, Fax +49 721 255171-100
    stefan.kelm@secorvo.de, http://www.secorvo.de/
    -------------------------------------------------------
    PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B



  4. #4
    Michal Zalewski
    Compromising pictures of Microsoft Internet Explorer!
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Compromising pictures of Microsoft Internet Explorer!

    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.
    Send mail to mime@docserver.cac.washington.edu for more info.

    ---1009447796-1606422298-1121296252=:15236
    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    Content-ID: <Pine.LNX.4.58.0507140110561.15236@dione>


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


    Just for the reference, this is confirmed to be fixed by the most recent
    (and long overdue) cummulative update for MSIE (a part of MS05-038):

    JPEG Image Rendering Memory Corruption Vulnerability - CAN-2005-1988

    A remote code execution vulnerability exists in Internet Explorer
    because of the way that it handles JPEG images. An attacker could
    exploit the vulnerability by constructing a malicious JPEG image that
    could potentially allow remote code execution if a user visited a
    malicious Web site or viewed a malicious e-mail message. An attacker
    who successfully exploited this vulnerability could take complete
    control of an affected system.

    Thought I'd clarify, because CVE seems to carry original references with
    one candidate entry (CAN-2005-2308), and Microsoft's patch with no prior
    references in another (CAN-2005-1988) - so there might be some confusion
    as to what was fixed and why. CERT and Securityfocus both include proper
    data, though.

    Cheers,
    /mz
    http://lcamtuf.coredump.cx/silence/

    ---1009447796-1606422298-1121296252=:15236
    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="index.cgi"
    Content-Transfer-Encoding: BASE64
    Content-ID: <Pine.LNX.4.58.0507140110520.15236@dione>
    Content-Description:
    Content-Disposition: ATTACHMENT; FILENAME="index.cgi"

    IyEvYmluL2Jhc2gNCg0KZWNobyAiQ29udGVudC1UeXBlOiB0ZX h0L2h0bWwi
    DQplY2hvDQoNCklEPSJ0aW1nLSQkLSRSQU5ET00tJFJBTkRPTS INCg0Kcm0g
    LWYgdGltZy0qIEFGWC5sb2cNCg0KY2F0IDw8X0VPRl8NCjxIVE 1MPg0KPEhF
    QUQ+DQo8TUVUQSBIVFRQLUVRVUlWPSJSZWZyZXNoIiBjb250ZW 50PSIwO1VS
    TD0vIj4NCjwvSEVBRD4NCjxCT0RZPg0KX0VPRl8NCg0KQ05UPT ANCg0KZm9y
    IGkgaW4gaW1nLyo7IGRvDQogIENOVD0iJFtDTlQrMV0iDQogIE ZOQU09IiRJ
    RC0kQ05UIg0KICBFWFQ9YGVjaG8gJGkgfCBjdXQgLWQuIC1mMm ANCiAgLi9h
    ZngtbG9jIC1wIDEgLWkgMTAwIC1tIFJBTkRPTSAtcyA2MDAwMC A8JGkgMj4k
    Rk5BTS4kRVhUID4+QUZYLmxvZw0KICBlY2hvICJUZXN0ICRDTl QgLSA8SU1H
    IFNSQz1cIiRGTkFNLiRFWFRcIj48QlI+Ig0KZG9uZQ0KDQo=

    ---1009447796-1606422298-1121296252=:15236--

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics