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

| 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> |
|---|---|---|
| ||
| Previous by Date: | [NEWS] Oracle interMedia DoS, SecuriTeam |
|---|---|
| Next by Date: | [TOOL] GoogleSweep - Google Information Gathering Tool, SecuriTeam |
| Previous by Thread: | [NEWS] Oracle interMedia DoS, SecuriTeam |
| Next by Thread: | [TOOL] GoogleSweep - Google Information Gathering Tool, SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |