FYI: this link to my blog was 404 until early this morning. It is now up if you are still interested in reading it. On 05-12-2016 11:55, Berend-Jan Wever wrote: > Since November I have been releasing details on all vulnerabilities I > found in web-browsers that I had not released before. I will try to > continue to publish all my old vulnerabilities, including those not in > web-browser, as long as I can find some time to do so. If you find this > information useful, you can help me make some time available by donating > bitcoin to 183yyxa9s1s1f7JBpPHPmzQ346y91Rx5DX. > > This is the twenty-fifth entry in the series. This information is > available in more detail on my blog at > http://blog.skylined.nl/20161205001.html. There you can find repros > that triggered this issue in addition to the information below. > > Today's release is interesting, as I accidentally published a repro for > this as part of #DailyBug on twitter in May of this year, believing at > the time that it was a simple NULL pointer: > https://twitter.com/berendjanwever/status/729957166447218688 > I found out not to long after that, that it was actually a security > vulnerability. Details on how this happened are below. > > Follow me on http://twitter.com/berendjanwever for daily browser bugs. > > MS Edge CBaseScriptable::PrivateQueryInterface memory corruption > ================================================================ > (MS16-068, CVE-2016-3222) > > 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 Edge > bug tracker and published it on twitter as part of #DailyBug. > > Soon after, I found another repro that trigger a slightly different NULL > pointer dereference in `CBaseScriptable::PrivateQueryInterface` in a > 64-bit version of Edge. > > 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 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 through the Edge bug tracker. > * 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. > > Cheers, > > SkyLined >
Attachment:
0x2557C5AA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
