Win10 TH2 BSOD vulnerability with Device Guard HVCI enabled

NTDEV
1

Just a follow up on a thread from a couple of months ago —> https://www.osronline.com/showthread.cfm?link=278206

We have been working with MSFT to investigate the root cause of this BSOD which presented strangely as a bugcheck 7E in GsDriverEntry, while running on Win10 Enterprise TH2 with Device Guard HVCI enabled.

MSFT has acknowledged that this vulnerability is a result of an OS deficiency in HVCI running in the Secure Kernel. They have just published a KB article on this —> https://support.microsoft.com/en-us/kb/3194715

Hope this information is useful to the community.

2

This has been a pretty interesting one, thanks for the update.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Just a follow up on a thread from a couple of months ago —>
https://www.osronline.com/showthread.cfm?link=278206

We have been working with MSFT to investigate the root cause of this BSOD
which presented strangely as a bugcheck 7E in GsDriverEntry, while running
on Win10 Enterprise TH2 with Device Guard HVCI enabled.

MSFT has acknowledged that this vulnerability is a result of an OS
deficiency in HVCI running in the Secure Kernel. They have just published a
KB article on this —> https://support.microsoft.com/en-us/kb/3194715

Hope this information is useful to the community.

3

It is interesting to note the different OS behavior and level of enforcement under HVCI when a boot-start driver is started at boot time vs. later.

Also, I believe that MSFT has said that drivers started at boot time are still backed by the pagefile.

4

xxxxx@gmail.com wrote:

We have been working with MSFT to investigate the root cause of this BSOD which presented strangely as a bugcheck 7E in GsDriverEntry, while running on Win10 Enterprise TH2 with Device Guard HVCI enabled.

MSFT has acknowledged that this vulnerability is a result of an OS deficiency in HVCI running in the Secure Kernel.

Technically, this is not a “vulnerability”. A “vulnerability” is
something that allows a malicious player to gain access to the machine
or its resources. This is a plain old “bug”.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

So the OS failed to mark the GsDriverEntry page as exec but the !pte command showed that the page was a read-only-exec page.

6

@Tim:

Thanks, you are right. I should have used a different word. Btw, MSFT has characterized this as an “OS deficiency” —>
“This is considered an OS deficiency. It?s not a bug because there is no code that was intended to work a certain way but does not. It?s not by design either because the design is still being worked out…”

That last sentence is troubling. Why would they have deployed something whose design is still being worked out?

7

> but the !pte command showed that the page was a read-only-exec page. <

I don’t think that the !pte command is able to read the extended page
table entry. It just reads what is visible to the guest partition.