Additional Details Released on the IIS Remote Buffer Overflow (Indexing Service, IDA)
19 Jun. 2001
Summary
A remote buffer overflow vulnerability affects all versions of Microsoft Internet Information Services (IIS) Web server software.
The vulnerability lies in the code that allows a Web server to interact with Microsoft Indexing Service functionality. The vulnerable Indexing Service ISAPI filter is installed by default on all versions of IIS. The problem lies in the fact that the .ida (Indexing Service) ISAPI filter does not perform proper "bounds checking" on user inputted buffers and therefore is susceptible to a buffer overflow attack.
Attackers that leverage the vulnerability can, from a remote location, gain full SYSTEM level access to any server that is running a default installation of Windows NT 4.0, Windows 2000, or Windows XP and using Microsoft's IIS Web server software. With system-level access, an attacker can perform any desired action, including installing and running programs, manipulating Web server databases, adding, changing or deleting files and Web pages, and more.
Credit:
The information has been provided by Marc Maiffret of eEye.
Vulnerable systems:
* Microsoft Windows NT 4.0 Internet Information Services 4.0
* Microsoft Windows 2000 Internet Information Services 5.0
* Microsoft Windows XP beta Internet Information Services 6.0 beta
Techincal details:
The below example will cause IIS to overflow one of its internal buffers causing it to overwrite the EIP address:
GET /NULL.ida?[buffer]=X HTTP/1.1
Host: werd
Where [buffer] is aprox. 240 bytes.
This buffer overflows happens in a wide character transformation operation. It takes the ASCII (1 byte per char) input buffer and turns it into a wide char/unicode string (2 bytes per char) byte string. For instance, a string like AAAA gets transformed into \0A\0A\0A\0A. In this transformation, buffer lengths are not checked and this can be used to cause EIP to be overwritten.
This sounds like any normal overflow to date, however there are a few sticking points in doing anything useful with this. First, you transform 2 bytes into 4, 2 of which you have no control over. This would be a bad situation, but not impossible to exploit. However, the 2 bytes that you do not have control over happen to be nulls. We need to take this 2 byte string and somehow get it to point to our code. Traditionally, we use our overwritten EIP to jump to a call ESP, or JMP ESP, jumping back to code we have positioned on the stack to implement whatever it is our shellcode would like to do. In this case, however, there is a problem.
GET /a.ida?[Ax240]=x HTTP/1.0
The above example overwrites EIP with 0x00410041. Again, traditionally, we insert our shellcode in the same buffer we overflow, however we run into the problem that then our code would also face the same expansion that our EIP bytes face. This makes writing shellcode a horrible pain. There are two methods of doing this:
1. Custom shellcode: It might be possible to write shellcode that works fine with NULL byes every other byte. It would probably have to be very simple, but this could be possible.
2. Encode: You could probably write a decoder that takes a string of 0x0041 and rewrites it on the stack into actual single byte code. This would have to be written completely in 0x00bb opcodes, most likely a challenge in itself (similar to the above custom shellcode, but only a decoder would need to be written).
This would, of course only be possible if we could find a point in memory that we could reach using only 0x00aa00bb. This gives us only about 65k spots in memory to look for jump bytes, a dismal situation.
Exploiting Wide Char Strings In Practice:
eEye got lucky using this method. They were limited to a very small range of memory in which to find jump bytes. They thought that they were losing the battle until we realized that IIS/ISAPI uses 0x00aabbcc as its memory range for allocated heap. Therefore, eEye developed a spray technique in an attempt to push enough data into the heap so that the bytes they required will be there when they need to jump to them.
For instance, in Windows 2000 Service Pack 1, eEye noticed that they had to request bytes at around 0x0042deaa. Since the closest they could get to this was 0x00430001 (by overflowing with C%01 at the end of our overflow string. This offered them an intriguing possibility -- perhaps they could push more stuff into a request, causing more heap memory to be used, pushing their request closer to where they wanted it to be.
GET /a.ida?[Cx240]=x HTTP/1.1
Host: the.victim.com
eEye: [Cx10,000][shellcode]
Now, they overflowed the EIP with 0x00430043. With they new much larger request, 0x00430043 happens to be inside the large C buffer they setup up. This acts as a slide in our code, executing down to our shellcode.
The Warning:
Now for the warning. With this technique of forceful heap violation, everything is relative to what is there to begin with. eEye noticed that in any situation, they found 4-5 different copies of their requests in the 0x00aabbcc memory range. This means that perhaps 0x430043 is not the best spot in memory, however it is the one they chose in their forthcoming sample exploit. The other potential problem with this attack is that different systems may have different heap usages. In their internal tests, they noticed that heap usage differed depending on which ISAPI extensions were enabled at any time. In addition, requests that cause faults handled by exception handlers that do not free their heaps may cause certain parts of the heap to become unusable, causing those spots to not be reused. This is not a problem for Windows 2000 because it is nice enough to restart it (giving us a nice clean heap to work with). Windows XP appears to act similarly, however eEye did not focus their research with this beta OS. This is, however, potentially a problem with NT 4, which will crash if exploited incorrectly. Again, like all other IIS overflows, this attack is not logged, causing only a fault in IIS and crashing it.
