Date: Tue, 6 Dec 2016 09:49:42 +0100
From: Berend-Jan Wever <berendj@...ver.nl>
To: fulldisclosure@...lists.org, Bugtraq <bugtraq@...urityfocus.com>
Subject: Re: CVE-2016-3222: MS Edge CBaseScriptable::PrivateQueryInterface
 memory corruption

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 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.
> 
> 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
> 

Download attachment "0x2557C5AA.asc" of type "application/pgp-keys" (2036 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists