Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Exploits-HackingTools
[Top] [All Lists]

[NT] Internet Explorer wininet.dll URL Parsing Memory Corruption (Techni

Subject: [NT] Internet Explorer wininet.dll URL Parsing Memory Corruption (Technical Details, MS05-020)
Date: 21 Apr 2005 16:30:48 +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.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  Internet Explorer wininet.dll URL Parsing Memory Corruption (Technical 
Details, MS05-020)
------------------------------------------------------------------------


SUMMARY

Axle 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 the program's logic. Buffer length is checked, but because of 
mistyping in the vulnerable code it fails to handle exceptional 
conditions. Vulnerable piece of code is located at address 0x771E8E85 
(wininet.dll version 6.00.2900.2180).

DETAILS

Vulnerable Systems:
 * Internet Explorer version 6.0
 * Internet Explorer version 5.5
 * Internet Explorer version 5.01

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

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 overly long hostname the resulting string length 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 targeted 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 memory 
chunks allocating.


ADDITIONAL INFORMATION

The information has been provided by  <mailto:3APA3A@SECURITY.NNOV.RU> 
3APA3A.
The original article can be found at:  
<http://www.security.nnov.ru/Idocument331.html> 
http://www.security.nnov.ru/Idocument331.html



======================================== 


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 


==================== 
==================== 

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




<Prev in Thread] Current Thread [Next in Thread>
  • [NT] Internet Explorer wininet.dll URL Parsing Memory Corruption (Technical Details, MS05-020), SecuriTeam <=