ANALYSIS OF THE ATTACK SURFACE OF WINDOWS 10 VIRTUALIZATION-BASED SECURITY
us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security
Kernel HVCI is based on secvisor • Separate EPT for code originating from signed and unsigned page • Root partition is configured so that any attempt by unsigned usermode code to enter kernelmode results in vmexit (and EPT flip) –IDT, GDT limits set to 0, syscall&sysenter disabled
Kernel HVCI and kernel exploits • Attackers love arbitrary code running in ring0 • SMEP a problem, but natural bypass: – Get ROP capability, then clear CR4.SMEP – Or, via write-what-where, clear U/S bit in PT – Run your arbitrary code • Not working with Kernel HVCI ! • Also, cannot hook kernel code, at least not directly • Data-only exploits, or ROP-only, still fine
- Page 1 and 2: Rafal Wojtczuk rafal@bromium.com AN
- Page 3 and 4: aScopeupa • Most of this research
- Page 5 and 6: aCredential Guard architectureupa P
- Page 7 and 8: aCG scenario 1upa • Admins just e
- Page 9 and 10: aNtlmIumProtectCredentialupa • In
- Page 11 and 12: aScenario 1 propertiesupa • After
- Page 13 and 14: aCG scenario 2upa • Credential Gu
- Page 15 and 16: aScenario 2 properties • No more
- Page 17 and 18: VBS-enforced code integrity • Win
- Page 19: Mixing signed & unsigned code • C
- Page 23 and 24: Kernel HVCI bypass, MS16-066
- Page 25 and 26: [Un]usual threat model • Usual mo
- Page 27 and 28: Root partition privileges • Acces
- Page 29 and 30: Root partition privileges • I/O p
- Page 31 and 32: Problem 1 - unfiltered MMCFG • MM
- Page 33 and 34: Problem 2 - chipset registers • S
- Page 35 and 36: S4 sleep • S4 is even more fragil
- Page 37 and 38: SMM • SMM is highly-privileged mo
- Page 39 and 40: SMM • It is well-known that SMM v
- Page 41 and 42: SMM abuse example
- Page 43 and 44: Summary • Despite its limited sco
- Page 45 and 46: Extra slides: Non-VBS-specific •
- Page 47: Other funny chipset capabilities
Kernel HVCI and kernel exploits<br />
• Attackers love arbitrary code running in ring0<br />
• SMEP a problem, but natural bypass:<br />
– Get ROP capability, then clear CR4.SMEP<br />
– Or, via write-what-where, clear U/S bit in PT<br />
– Run your arbitrary code<br />
• Not working with Kernel HVCI !<br />
• Also, cannot hook kernel code, at least not directly<br />
• Data-only exploits, or ROP-only, still fine
Change language