Related Weaknesses
| CWE-ID |
Weakness Name |
Source |
| CWE-119 |
Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
|
Metrics
| Metrics |
Score |
Severity |
CVSS Vector |
Source |
| V3.0 |
8.8 |
HIGH |
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
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. Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component. 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 total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. 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 a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to 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 total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable). 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 |
9.3 |
|
AV:N/AC:M/Au:N/C:C/I:C/A:C |
[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 : 40880
Publication date : 2016-12-05 23h00 +00:00
Author : Skylined
EDB Verified : No
Source: http://blog.skylined.nl/20161205001.html
Synopsis
A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Edge. I did not investigate this vulnerability thoroughly, so I cannot speculate on the potential impact or exploitability.
Known affected software and attack vectors
Microsoft Edge
An attacker would need to get a target user to open a specially crafted web-page. Disabling JavaScript does not prevent an attacker from triggering the vulnerable code path.
Discovery
This issue was found through fuzzing in the 64-bit version of Microsoft Edge, in which the original repro triggered what appeared to be a NULL pointer dereference in CBaseScriptable::PrivateQueryInterface. So, after a very brief look at the repro, I filed a bug in the public bug tracker and published it on twitter. The original repro was:
<body onload=typeof(open().crypto)>
Soon after, I found another repro that trigger a slightly different NULL pointer dereference in CBaseScriptable::PrivateQueryInterface in a 64-bit version of Edge. The second repro was:
<body onload=typeof(open().msCredentials)>
I never tested the these two repros in a 32-bit version of Edge before publishing them, which I immediately regretted after finding that the second repro triggered an access violation using the obviously non-NULL address 0x1BF37D8 in a 32-bit version of Edge!
Around this time, I started finding many variations of this bug: getting the type of various properties or objects associated with another window was triggering all kinds of access violations. Many of these were not using NULL pointers on 32-bit Edge. I collected all the variations my fuzzers had found and come up with these additional repros:
<body onload=typeof(open().document.createElement("canvas").getContext("2d"))>
This triggered an access violation in edgehtml.dll!CBaseScriptable::PrivateQueryInterface while attempting to read from address 0x4C261 in the 32-bit version of Edge.
<body onload=typeof(open().navigator.mediaDevices)>
This triggered an access violation in charkra.dll!ThreadContext::PreSweepCallback while attempting to read from address 0xFF80A90F in the 32-bit version of Edge.
<body onload=typeof(open().toString)>
This triggered an assertion failure because it was calling a deprecated API in the 32-bit version of Edge.
I looked again at the original crypto repro and noticed that although it triggered an access violation using a NULL pointer on both 32-bit and 64-bit versions of Edge, the two addresses (3 and 8 respectively) had different alignment. This is rather odd: true NULL pointer dereferences can cause an access violation at a different offset from NULL on these two architectures because property values and pointers stored before the one being read/written can have different sizes on 32-bit and 64-bit systems, but one usually expects them to have similar alignment: the last two bits of the address should be the same.
Report
If only I had tested the original repro in a 32-bit version of Edge when I first analyzed the issue, I might have realized it was more than a simple NULL pointer and not published it before doing additional research.
I contacted ZDI and asked if they would be interested in buying the vulnerability at this point, given that I publicly released the repro that triggered a NULL pointer and filed it with Microsoft. I was hoping they would decide that this did not disclose the underlying vulnerability and that it as such would still be a 0-day. Unfortunately for me, they were not interested in acquiring details in this situation.
At that point I decided to contact the Microsoft Security Response Center and report the additional information I had found. I also contacted a few people working on the Edge team at Microsoft directly to let them know they might want to escalate this bug from a simple NULL pointer to a security vulnerability. Unfortunately, this let them to decided to mark the bug I had filed in the Edge bug tracker as hidden. I warned them that this did little good, as the details were still public in my twitter and even if I deleted that, in general what goes on the internet stays on the internet.
Analysis
Since I had publicly released the repro, I was not going to be seeing any kind of reward for this bug, so analyzing the issue was not a priority for me. Unfortunately that meant I did not analyze it at all, other than to speculate that this bug was likely to have been a type-confusion or bad cast, where assembled code was used as data, leading to most of these repros triggering an access violation at a static address that depended on the code they were using as data. It may therefore be possible to find a variation that uses code that represents an address in the address space of Edge where an attacker might store data under his/her control. This is especially true for 32-bit Edge, as the address space is a lot smaller. Depending on what the code does with the address, it might be possible to execute arbitrary code under perfect circumstances.
On Hiding bugs in public bug trackers
Hiding a publicly reported bug after the fact is a very bad idea IMHO, as it paints an easy to detect target on the bug. Every smart attacker should have a system that makes regular copies of all publicly reported bugs in target applications and reports to their owner all bugs that become hidden, with a copy of all the information it scraped from the bug before it was hidden. Since hiding a public bug only ever happens for one of two reasons: the bug was found to be a security issue, or the report accidentally contains personal information that the owner wants hidden. It should be quite easy to distinguish between the two to filter out the vulnerabilities, giving an attacker a nearly free stream of nearly 0-day bugs. If you work on a team that has a public bug-tracker, you may want to discuss this with your team and decided how to handle such situations.
Conclusion
As useful as BugId is in automating a lot of the analysis I do on every bug I find, and in helping me prioritize the issues that are most likely to be vulnerabilities, it is not perfect and cannot always detect a vulnerability for what it is. BugId is not a perfect replacement for full manual analysis of bugs.
In this case I relied to heavily on its ability to distinguish vulnerabilities from other bugs. Because of the nature of this issue, the repros caused access violations at static addresses, many of which near enough to NULL to be interpreted as NULL pointer dereferences, especially for the first repro I found. BugId can not actually determine the root cause of a crash, but attempts to deduce the root cause based on the details of the crash it causes. In this case, the crash looked too similar to a regular NULL pointer dereference for BugId to detect it as anything else.
However, in my current situation, where I am finding way more bugs than I can analyze manually, BugId does a very good job at helping me prioritize and analyze issues. I have used BugId on hundreds of bugs and, as far as I know, this is the first time I mistook a security vulnerability for a regular bug based on the BugId report. As such, the false-negative rate I have experienced is a fraction of a percent, which IMHO is remarkably low and entirely acceptable. At the same time, the false-positive rate I have seen so far is exactly zero.
In order to prevent this from happening in the future, I now test each repro in both the 32-bit and 64-bit version of Edge, do more manual analysis on bugs that get reported as a NULL pointer with a non-DWORD-aligned address (e.g. 3 in this case), and wait slightly longer for my fuzzers to find variations of a bug before I start my analysis and report the issue as a non-security bug.
Time-line
29 April 2016: This vulnerability was first found through fuzzing.
10 May 2016: This issue was published on Twitter and reported to Microsoft.
13 May 2016: This vulnerability was submitted to ZDI.
18 May 2016: This vulnerability was declined by ZDI.
18 May 2016: This vulnerability was reported to MSRC and I informed Edge developers directly on the seriousness of the bug.
18 May 2016: The issue was hidden in public bug tracker.
14 June 2016: Microsoft addresses this vulnerability in MS16-068.
December 2016: Details of this vulnerability are released.
Products Mentioned
Configuraton 0
Microsoft>>Edge >> Version -
References
