Microsoft Silently Fixes Kernel Bug That Led to Chrome Sandbox Bypass

Microsoft appears to have silently fixed a two-year-old bug in in Windows Kernel Object Manager that could have allowed for the bypass of privileges in Google’s Chrome browser.

Microsoft appears to have silently fixed a two-year-old bug in in Windows Kernel Object Manager that could have allowed for the bypass of privileges in Google’s Chrome browser.

James Forshaw, a researcher with Google’s Project Zero first reported the issue in December 2014. Microsoft responded to Google a month later saying it didn’t consider the issue worthy of a fix. Forshaw and Google marked the issue as “WontFix” and removed the view restriction on the disclosure. It’s been more or less on ice since then.

Microsoft’s stance changed at some point over the past 23 months however; Forshaw acknowledged in a post on the Project Zero Google Group early Wednesday morning that Microsoft has fixed the issue in a recent Windows 10 fix. It’s unclear whether Microsoft addressed the issue in a hotfix or via a silently issued patch but according to Forshaw, it has been reflected in the “latest few major builds of Windows 10 (10586+)”

The issue, a limited bypass of traverse permissions, affected the Kernel Object Manager in Windows 7 (32/64 bit) and 8+. In 2014, Forshaw warned it could be possible for low privilege code to “access some device objects where it shouldn’t be possible [to] even determine they exist” in Chrome.

Chrome’s sandbox token is fortified – its traverse permission is heavily enforced, according to Forshaw – but this issue slightly diminished that.

Forshaw called the issue a “limitation” for Chrome when he originally highlighted the issue and admitted he didn’t expect it would ever become a “bulletin class issue, if it’s considered an issue at all.” If anything, he said it could result in a “minor security impact for Chrome.”

Forshaw wrote Wednesday that he wasn’t sure what led Microsoft to fix the issue.

Microsoft, for its part, did not immediately respond to a request for comment on Wednesday.

Forshaw couldn’t speak directly to the issue when reached on Wednesday but pointed Threatpost to an updated post he had made on the issue tracker:

“For anyone who’s wondering if this is unusual for Microsoft that they fixed it so long after reporting, not really. If MSRC and by inference the product team do not consider the issue to meet their bar for a security bulletin (as mentioned in comment #2) then they’ll tend to not fix it in a patch. However they do leave themselves open to fixing it a later update of the platform, which for Win10 is becoming more frequent.”

Forshaw adds that the fix may have been pushed inadvertently as other users of the function in question, SeCreateAccessState, may have been affected.

“The trouble with this approach is there’s never any credit or notification for the fix and so I was under the impression that this issue still existed,” Forshaw said.

Suggested articles

Discussion

  • Anonymous on

    did windows 7 and 8.1 get patched?
  • JL on

    Pointless article since neither Threatpost nor Google Chromium provide a link to the specific Microsoft patch.
    • Dan Neely on

      No, that is a big part of the post. At some point between MS saying they wouldn't fix the bug in 2014 and when James Foreshaw discovered that it had been fixed on Nov 30, 2016 MS did fix it *without* saying they did so. That leaves only the tedious process of taking a 2 year old windows install and updating it 1 patch at a time (fighting MS's desire to use rollups in W10 to patch directly to the current build all the way) to find out which patch included it without documenting the fact. An almost totally worthless waste of time.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.