Internet Explorer wininet.dll URL parsing memory corruption technical details

From: 3APA3A (3APA3A_at_SECURITY.NNOV.RU)
Date: 04/14/05

  • Next message: mikx: "Firelinking [Firefox 1.0.2]"
    Date:         Thu, 14 Apr 2005 19:28:48 +0400
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

    Vendor: Microsoft
    Software: Internet Explorer 6.0, 5.5, 5.01
    Problem: Memory corruption, code execution
    Remote: Yes
    Risk Level: Medium to low (hard to exploit)
    Authors: Axle (ICQ 755756) bug discovery
                    3APA3A, http://www.security.nnov.ru/ bug research
    Original URL: http://www.security.nnov.ru/Idocument331.html

    Details:

    Axle (ICQ 755756) found an interesting and hard to catch bug in
    InternetCreateUrlW function of wininet.dll. It's hard to find, because
    in most cases vulnerable application doesn't crash and it can not be
    found with automated code scanner, because it's not typical buffer
    overflow, but the bug in program logic. Buffer length is checked, but
    because of mistyping in vulnerable code it fails to handle exceptional
    conditions. Vulnerable piece of code is located at address 0x771E8E85
    (wininet.dll version 6.00.2900.2180).

    This part of code should convert hostname from Unicode. Whole process is:

    1. Calculate size of target buffer (exactly twice more than actually
    required to make you buy additional memory).
    2. Allocate buffer with LocalAlloc()
    3. Copy string to target buffer with WideCharToMultiByte()
    4. NULL-terminate target string, which is already NULL terminated to add
    additional CPU cycles. It's required to make you buy faster processor.

    It clearly confirms Microsoft has contract with Intel. Joke. Probably.

    If translate to C this code looks like

    /* 771E8E85 */
    if (stringlen == 0) {/* handle exceptional conditions */}
    /* the bug is here. Should be stringlen <= 0 */
    else {
         ...
         /* stringlen is -1 on oversized hostname */
         buflen = (stringlen)*2 + 2 /* buflen is 0 */
         buf = LocalAlloc(0, buflen); /* because LMEM_MOVEABLE is not set LocalAlloc returns
                                      zero size page from heap*/
         /* 771E8EC1 */
         len = WideCharToMultiByte
                                 (0,
                                  0x400,
                                  pointer_to_hostname,
                                  -1 /* NULL terminated/,
                                  buf,
                                  buflen /* size of allocated buf */,
                                  NULL,
                                  0);
                  /* because cbMultiByte is 0 WideCharToMultiByte simply calculates
                       required length, it's equal to real length of our hostname, it doesn't
                       change content of memory pointed by buf) */

         /* 771E8EC6 */
         buf[len] = 0; /* here 0 is written to some unallocated memory and we can
                         partially control address by the length of our hostname */
     ...
    }

    The problem is on oversized hostname stringlen is -1, not 0 as expected.
    So we have:

    1. Calculated buffer size is 0.
    2. LocalAlloc returns valid pointer to empty chunk.
    3. Because targed buffer is empty, WideCharToMultiByte() does not
    actually copies any data, but only calculates length of hostname string.
    It prevent direct buffer overflow.
    4. As a result we can write single '\0' byte to partially controllable
    (with hostname length) location.

    Because translated hostname points to empty memory chunk it contains
    some garbage. In most cases it's only visible effect (you see garbage in
    address bar of Internet Explorer). In rare cases than empty chunk is at
    the end of memory page on the heap Internet Explorer crashes.

    Example:

    <a href='http://>/'>TEST (CLICK)</a>

    Theoretically, this bug is exploitable, because we can manipulate with
    memory chunks allocating, e.g. with Javascript or page redirections. In
    practice it's very hard for lazy person.

    References:
    1. Multiple Microsoft Internet Explorer memory corruptions
    http://www.security.nnov.ru/news4675.html
    2. Microsoft Security Bulletin MS05-020
    Cumulative Security Update for Internet Explorer (890923)
    http://www.microsoft.com/technet/security/Bulletin/MS05-020.mspx
    3. URL Parsing Memory Corruption Vulnerability
    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0554
    4. Microsoft Windows Internet Explorer Long Hostname Heap Corruption Vulnerability
    http://www.idefense.com/application/poi/display?id=229&type=vulnerabilities

    --
    http://www.security.nnov.ru
             /\_/\
            { , . }     |\
    +--oQQo->{ ^ }<-----+ \
    |  ZARAZA  U  3APA3A   } You know my name - look up my number (The Beatles)
    +-------------o66o--+ /
                        |/
    --
    NTBugtraq Editor's Note:
    Most viruses these days use spoofed email addresses. As such, using an Anti-Virus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered.
    --
    

  • Next message: mikx: "Firelinking [Firefox 1.0.2]"

    Relevant Pages

    • Bug Check In NDIS Intermediate driver. DRIVER_CORRUPTED_EXPOOL (c5) and BAD_POOL_CALLER (c2)
      ... I am having really hard time tracing these two bug checks in my NDIS ... When i try to free the memory in my driver. ... When i receive back the the packet then i try to free the VM, ... //Here we have to free all the buffer and memory.. ...
      (microsoft.public.development.device.drivers)
    • Internet Explorer wininet.dll URL parsing memory corruption technical details
      ... Internet Explorer 6.0, 5.5, 5.01 ... 3APA3A, http://www.security.nnov.ru/ bug research ... because it's not typical buffer ... Because translated hostname points to empty memory chunk it contains ...
      (Bugtraq)
    • [Full-disclosure] Internet Explorer wininet.dll URL parsing memory corruption technical details
      ... Internet Explorer 6.0, 5.5, 5.01 ... 3APA3A, http://www.security.nnov.ru/ bug research ... because it's not typical buffer ... Because translated hostname points to empty memory chunk it contains ...
      (Full-Disclosure)
    • Re: IE Application error "0x08de454d"
      ... all problem solving begins *after* your computer is 100% free of any kind of malware. ... "Ted Zieglar" wrote: ... Malfunctioning RAM - the hexadecimal numbers you are seeing are memory addresses. ... A program active on your computer is not releasing its grip on a memory address, making it impossible for Internet Explorer to shut down on its own. ...
      (microsoft.public.windows.inetexplorer.ie6.browser)
    • Re: IE Application error "0x08de454d"
      ... Malfunctioning RAM - I have never tried that before. ... "Windows Memory Diagnostic" ... What program would exhibit such chutzpah to Internet Explorer? ... control or a browser helper object. ...
      (microsoft.public.windows.inetexplorer.ie6.browser)