This month, Microsoft released an update for IIS that addresses three vulnerabilities. The blog post focuses on one of these: the Request Header Buffer Overflow Vulnerability (CVE-2010-2730), which affects IIS version 7.5 and has a maximum security impact of Remote Code Execution (RCE). Below we provide more details on the vulnerability and the potential for reliable remote code execution, to assist with assessing risk and prioritizing deployment of the update. We also aim to allay fears of malware utilizing this vulnerability to spread across networks.
CVE-2010-2730 affects Windows servers running IIS with a non-default configuration. If the FastCGI handler is enabled (e.g. to support 3rd-party server-side scripting languages), the system could be vulnerable to a heap buffer overrun when handling HTTP request headers.
A successful exploit would allow a remote attacker to execute code in the context of the IIS worker process.
For more details, refer to Security Bulletin MS10-065.
While a successful exploit leading to RCE is possible in theory, there are some technical factors that make it less likely. In practice it is more likely that attacks will lead to a crash of the IIS worker process and a denial-of-service (DoS) condition when the service reaches its restart limit. Let’s look into the factors that hamper exploitation:
The vulnerable code processes HTTP request headers from the client - these are under the attacker’s full control. An initial buffer is allocated on the heap and used to store the request header names and values, and is re-sized as needed, until all the client’s headers have been processed.
At this point, no buffer overrun has occurred. The code then proceeds to copy pre-defined parameters to the buffer, assuming that enough space has been reserved by the earlier code. In some cases this will lead to a buffer overrun. The data written to the buffer is of the following format:
Name : string pointer NameLen : integer Value : string pointer ValueLen : integer
At the point the buffer overrun occurs, only the Name and NameLen fields are populated (non-zero) – the code will retrieve values for each of these parameters once they have been appended to the buffer.
The important thing to note is that none of the data that is written beyond the end of the buffer is under the attacker’s control. The Name fields will point to string data in the IIS worker process. The pointer values will be unpredictable due to ASLR. The NameLen fields will be predictable low-value integers, but will not be of much use to an attacker.
Once the values for these parameters have been filled in, the Value field will point to string data and ValueLen will also be a low-value integer. (The contents of the strings may be attacker-controlled).
In order to obtain a reliable RCE exploit, the attacker would need to be able to predict or control the values outlined above, and also control the layout of the heap buffers to some extent. Due to the lack of control or predictability of the data written beyond the end of the buffer, this vulnerability will be tricky to impossible to exploit reliably.
For this reason, attempts to exploit this vulnerability are more likely to result in a DoS than RCE.
I would like to thank Nazim Lala, Bruce Dang and Charles Weidner for their work on this issue.
- Mark Wodrich, MSRC Engineering
*Posting is provided "AS IS" with no warranties, and confers no rights.*