exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

wininet.dll_unicode_overflow.txt

wininet.dll_unicode_overflow.txt
Posted Apr 20, 2005
Authored by 3APA3A | Site security.nnov.ru

The InternetCreateUrlW function of wininet.dll, a core component of Internet Explorer, is vulnerable to a buffer overflow attack when the source buffer is copied into the destination buffer using WideCharToMultiByte. In practice this is probably only useful for Denial of Service attacks (if that) and still requires some social-engineering to actually exploit this.

tags | advisory, denial of service, overflow
SHA-256 | ff53458ff1c02389c39168172c59ac6ab1cbb62bfdb0fc78469a4dc9190da6ca

wininet.dll_unicode_overflow.txt

Change Mirror Download

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://<buffer_of_256-300_bytes>/'>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--+ /
|/

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close