BugTraq
WININET CHttpHeaderParser::ParseStatusLine out-of-bounds read details Nov 10 2016 09:49AM
Berend-Jan Wever (berendj nwever nl)
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
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQINBFeg3+kBEACfJ83XEx+3CXfc2pyDlZ5+DFSvhdvbSvemqEckOtrQxTYOmH/8
6WrX2B7K6eyolLCIQMi0FjXK5hjJJFYTMrhoa7pP9V9PD2f4TI+tZv+g0D8wDVam
wYsZrFB6NwzyUaBykjj4chYxxzUxTwagwCxvrGNY871tiVWV5eR3TrKRcsFwzN53
G3lhAT974YRCIBMuA6y+3Jrd8hgfODWUtYsH4WPhaLJRr9qaatN+Fnpk+rb9X62C
EqcVXhgNeIz1j/K3I3XoHqMThNu5zbv7uQrp2j+/0fZjKXxZ7HZhTKzIFTrJkrTA
jQ34iq0qgXmLltpKtOLJKhPQPb8J/N0MxOOTa34BDeSiqwlcRzkl7lYTIl7hvvCn
lSRbu+PoAW0GrD17RAA9FQoqdDDiNLHlXnjx7Jg/Tchq1EF70hKzMojcwyjPilty
HJRtPq/sZEdjwEuA5fM+3cmkmRWZYXmn93rB2KTNlGXo+7II6eXx1E6iw7MBzhV5
+mB9A/6FLPhb6TY7TrWOKC65uEtYjHArcb2WeB7/6g9r0nPcBzFiXt35U+YdbmiH
Qt4L5aivYI3WNwQh391Q8QH8i1C0DTI0TCoinzBHzySJfiQ5IP8BUmPIKJWxSeiF
Od5Fv3bz7S7DihtP+i7XyChoHVAleu9tk4/kIQlJ/PPbBpRAYFhQKwSX3QARAQAB
tCRCZXJlbmQtSmFuIFdldmVyIDxiZXJlbmRqQG53ZXZlci5ubD6JAj8EEwEIACkF
Aleg3+kCGw8FCQIDCbcHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCdHa2I
JVfFqn6TD/0aQmgvFcwoAOn52NujoEgl5LxdvcrPgDaZK10kuolsA2u/IaB4J3yY
c2Z8kTfGOg5ObCBHlq6B9qYn3ptr+C0ICuYENIVoHdcBgdK9JXscRWrOU8JI69mj
gmsKNLei+AuBGGC7LJOV6JNqYkVieukkFQkv17pvFl63GqNcVkwEXIzzeGOHYHqA
dvPR7xTZu+dA2olB2BVC9XsWJpsxJqzuX8L3wOEn1EFAhlbeSlBo2kXB04DnjUXU
qHa9M2PZ4q0xWmD+iAThTdyoB+FvSvn6+ThFhig99dOsx8ZLS/QRwMoq1qgN1Nst
YFZgCUuGqwR7d0Dr8/Vb1qzQmIPtn/JCjbFNuIssGRA3tDVwTvEmgfAhpVApuS8f
bNWGV2fQmEfLShqXOI/GfEYt8ltoozKKTYRiXt7oqsrLGWjXJ6SZAYcFHOCc9CbC
TukyDyndVIWAwJRSr9SHKyokElnJBeiGW9rMwITW4BRf7YfXNwHHOFW95esbNIEF
sL37BfzBoTNDUShajB8kVKJv0LE5OZArsQfz2yBXoU2AyvGEvbYdt0q53+FwGzX/
EtqkcFYqwKkxurjn8Nkk4x4hjoiUmXHj45G/MgwLxY8Skf6RvBr0eu4Mh7FxoTRP
LX5hIpGbCO3umoGbHNGkJcEw5S9oIQdb3ysf5HVLi7Pw6AIfJZWSfIkBHAQQAQgA
BgUCV6S2FwAKCRBf2KWWmuk+Yng/B/0f/nSDAnmXAiZ2HPi/ujfAEzFPWmahZJVv
Ih9DjuRUV6vk1B9Sh+yiPPZ3FfqOzVE0n6Eh1Kggs6MwQCWv+NfC0KE6rQwxjMce
+eOAf9dbVQ8h6H4yGyIyb4f0tJFRyGpOK8zlKwjvPj2gvTZFjcc1PaZ7cIeuwheB
Ijtw9DQWIoQoFFHZkLHxmNo8IT+r7lB19rVWoh1pu/zfuC+xjQLCpzexafFGY3TT
Fz7YdO14F61sJjrf++9twRi7RoHWGnAcFCZynG6x4jyog1u9iKMK2T2nV5yyQg21
yhw4zEV1pKDwUdHK+TwmtyD5c6oL3IjNDWaHn0aejKgfEiiLUBLe
=anIL
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYJEKaAAoJEJ0drYglV8Wqmk8P/j7r4jXz5G7CvpMU3S6Os1hu
s/+JAJ48Jw/ay+UA77GaKVgCZU+tXtFhyYTm8k+N6MIjS6OJz2R6rTqYsIrf4etG
i69cZPMZhhY7jTX+n61XicTN7sE9XEgguboNJrl8eu371h+ULm2gJrwar1kZc4ed
I0PmSYWHFm2Vg8pyQ/BuzE2oKwCRBAiUKIJWpBtTfNv4v6ulS++uH6NUQzujBOak
TUdEhWtWyomQREabPOW9NeLItRTqEqep6pOCqMdvCucxOw3pRNrdoBVJv59ovuMc
/NTfzUNpAQ2z/JQL+Q8GcDuC8UmpXCSR5qjjHq2xg4NTsrW3FVWwgtx5UIoSiweN
5uXf/iU3pqMI72Pqy/s8wwkaVptXiCTW7C1HHyHUqXRrFXqD3f/i3JNAYnavEQ6K
lwodxrVu+G/9g/0Qv/7kOyLgIOiuLtMmXrUg2/6omKsxlpDrLY4M2oejqy1diPdu
rxN46H5vfT+CM9UMPHnGFUWr8D8cs03h/qd2FTi4CUcqADt89mJevRFa/K78zBxL
3moNFshN1SzznMY26N2pIFVOH2oKGOBugF1Uo4+k9gFGQCfLAqbmrPkwYJkuz1Qa
miVnRW8edE0Ww0Sxib3QuL1m2hdPWbbsnG44t9WxV4HY/AWJCDiC8sko+2Fqwru4
DAdAyKzPHmGzaWxRBkkz
=f/Va
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus