Hardening with Hardware
How Windows is using hardware to improve
security
David “dwizzzle” Weston
Device Security Group Manager
Microsoft, Windows and Devices
“_____ is not a security
boundary”
Security boundaries are changing
Russinovich - Windows and Malware: Which Features Are Security and Which Aren't
Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer
anymore.
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
Law #4: If you allow a bad guy to run active content in your website, it's not your website any more.
Law #5: Weak passwords trump strong security.
Law #6: A computer is only as secure as the administrator is trustworthy.
Law #7: Encrypted data is only as secure as its decryption key.
Law #8: An out-of-date antimalware scanner is only marginally better than no scanner at all.
Law #9: Absolute anonymity isn't practically achievable, online or offline.
Law #10: Technology is not a panacea.
Ten Immutable Laws Of Security
Law #3: If a bad guy has
unrestricted physical access
to your computer, it's not
your computer anymore.
We aspire to do more
XBOX One X features glitch Custom SoC provides high
1 protection for physical 2 performance streaming
hardware attacks crypto support
Hardware supported
Hypervisor supports
3 Hardware supported
isolation of multiple security
domains Memory
4
encryption/decryption and
integrity check capability
Segmentation
Performance
Smaller attack surface
Can we use hardware
capabilities to redefine
Windows security
guarantees?
All code executes User identities Attacker with
with integrity. cannot be casual physical
compromised, access cannot
spoofed, or stolen. modify data or
code on the device.
Malicious code Violations of All apps and
cannot persist on a promises are system
device. observable. components have
only the privilege
they need.
All code executes with
integrity.
Technologies for mitigating code execution
Code Integrity Guard Arbitrary Code Guard
Prevent arbitrary
code generation Images must be signed and loaded Prevent dynamic code generation,
from valid places modification, and execution
Control Flow Guard ???
Prevent control-
flow hijacking Enforce control flow integrity Enforce control flow integrity on
on indirect function calls function returns
Only valid, signed code pages can be Code pages are immutable and Code execution stays “on the rails”
mapped by the app cannot be modified by the app per the control-flow integrity policy
Hypervisor Enforced Code Integrity
Normal Mode (VTL0) Secure Mode (VTL1)
SLAT is used to gate enforce RX only
HVCI running in SK validates code pages
If valid set GPA bits to
User R=1 W=0 KMX=UMX=1
NT Kernel NT Kernel
mode
Kernel
Mode-Based Execute (MBE) Control
mode
Extended-Extended Page Tables (EPT)
Kernel Pool
Kernel Pool Page
NT Kernel Secure Kernel
• XU for user pages
• XS for supervisor pages
• KMX and UMX hardware bits.
Improves HVCI performance
Available on Skylake+
Kernel Control Flow Integrity
Compile time Kernel Runtime
void Foo(...) {
// SomeFunc is address-taken
Image • Update valid call target data with
Load metadata from Driver image
// and may be called indirectly
Object->FuncPtr = SomeFunc;
}
Metadata is automatically added to the image which identifies functions that may be
• HVCI validates and maps pages
HVCI
called indirectly
• CFG bitmap is protected by HV
void Bar(...) {
// Compiler-inserted check to
// verify call target is valid
_guard_check_icall(Object->FuncPtr);
Object->FuncPtr(xyz); Indirect • Perform O(1) validity check
Call
}
• Terminate process if invalid target
A lightweight check is inserted prior to indirect calls which will verify that the call target is
valid at runtime
Kernel Control Flow Guard improves protection against control flow hijacking for kernel code
Paired with HVCI to ensure both code integrity and control flow integrity
OSR REDTEAM targeted kCFG bitmap data corruption, now protected by Hypervisor (props to davec!!!)
Starting in 1803 all new Windows installs will include HVCI by default (MBEC/Kaby Lake+)
This helps Windows improve resilience to future kernel exploits
VBS has created new attack surfaces
External researchers and OSR REDTEAM highlighted SMM risks for VBS
Arbitrary code execution in SMRAM can be used to defeat Hypervisor
Malicious code running in SMM is difficult to detect
New Attack Surface, New Mitigations
Windows SMM Security Mitigations Table (1607) Windows System Guard with TXT (future)
FIXED_COMM_BUFFERS
SMM will validate that input and output
SMM reference code + hardware support for
buffers lie entirely within the expected establishing SMM page tables and
fixed memory regions. protecting them
COMM_BUFFER_NESTED_PTR_P SMM will validate that input and output
ROTECTION
pointers embedded within the fixed Using measurements for attestation for
communication buffer only refer to modules in SMM that establish isolation and
address ranges that lie entirely within the
expected fixed memory regions. attest to the isolation properties using PCR’s
SYSTEM_RESOURCE_PROTECTIO Firmware setting this bit is an indication
N
that it will not allow reconfiguration of
system resources via non-architectural
Building out hardware support for isolating
mechanisms. SMM in a direct container
Windows is investing heavily in current and future SMM based mitigations
Capsule update mechanisms in WU enables OEMs to service firmware security issues
Intel firmware bounty covers all tianocore components
Return address protection with hardware
Initial attempt to implement stack protection in
software failed
Return EIPn-1
REDTEAM designed software shadow stack (RFG) did Param 1
not survive internal offensive research
Param 2 Return EIPn-1 +4
Control-flow Enforcement Technology (CET) ESP Return EIPn SSP Return EIPn +0
after after
Indirect branch tracking via ENDBRANCH
call call
Return address protection via a shadow stack Stack usage on near CALL
Call pushes return address on both stacks
Hardware-assists for helping to mitigate control-flow
hijacking & ROP Ret/ret_imm
pops return address from both stack
Execption if the return addresses don’t match
Robust against our threat model No parameters passing on shadow stack
Malicious Code Cannot Persist
on a Device.
Secure Boot: Static Root of Trust
Secure Boot implementation
includes OEM UEFI in the root-of
trust TCG User Mode Apps HVCI
VSM
OS
TPM file
1.2/2.0
UEFI code is complex and servicing Other Drivers software
is not mature firmware
ELAM Drivers
hardware
UEFI
Boot Manager OS/kernel Drivers
Secure
Dozens of vulnerabilities
discovered in UEFI in recent years
OPROMs
OS Boot Loader Boot
ChipSet Init
NIC GPU BMC Hypervisor
System Guard: Dynamic root of Trust (TXT)
Boot Flow
OEM Pre-Boot Code Trusted Launch Code Initialize and launch Hypervisor
OEM Pre-boot code boots and initializes HW. Completes initialization of hypervisor and secure
MS Trusted Launch Code measures and loads kernel
UEFI code transitions to boormgr and Winload. the rest of hypervisor (HV) and secure kernel
Must not use any UEFI services
(SK)
Winload used UEFI service to load HV and SK
Jump back to Winload and supervisor mode when
into memory Enables IOMMU and SMI done
Invokes SINIT instruction to enter trusted launch Must not use any UEFI services Winload can use UEFI services again to boot rest of
code Windows
Continue to measure Rest of HV/SK measured
SINIT Measures HV/SK launch code into into PCR18..PCR22 as it
Trusted launch code PCR18..PCR22 boots
into PCR17 & PCR TPM:
18 Measurement of
Launch Code/HV/SK is in
Health Attestation Servers can PCR17 .. PCR22 of TPM
confirm CPU is running secure
HV/SK using TPM PCR17 ..
PCR22 values
System Guard with DRTM
Attacker with casual physical
access cannot modify data or code
on the device.
Windows DMA-r Attack Protection
Wait for user
Peripheral User logged in
to login/
Connect peripheral Drivers opted- No AND Screen No
unlock
in DMAr? unlocked?
screen
Yes
Yes
Enable DMAr for
the peripherals
New devices are
enumerated and
functioning
User OS
All apps and system
components have only the
privilege they need.
Containment with Virtualization
Privileged Access Workstation Strengths
Strong kernel isolation for applications running
Desktop PAW in the guest
Separate identity and resource infrastructure
V-Switch V-Switch
Can be extended to arbitrary application
Locked down host
scenarios
Qubes OS Weaknesses
High resource requirements
Difficult experience for non-technical users
Expensive configuration
Dual Containment Technologies
Windows Containers
• Lightest weight container. • Container providing an • Container that uses a • Container that uses a
• Application isolated using isolated the user session lightweight VM lightweight VM
file system and registry • Shares kernel • Resistant to kernel • Hypervisor boundary.
virtualization. • Used to achieve higher attacks Runs a separate • Used in hostile multi-tenant
• Used for centennial as a density in cloud and kernel from the host. hosting.
bridge server deployments. • Commercially known as a
• No Security guarantees • No a security boundary “Hyper-V container”
Krypton Container Technology
Direct Map Memory Enlightenment Integrated Scheduler
Resource sharing between Physically-backed VMs statically No scheduler in the hypervisor
guest and host mapped
Remove extra scheduling layer
VM accesses a file, data is VA backed VMs have “hot hint”
transferred into physical pages indicate set of physical pages Take advantage of the existing
of the guest should be mapped into the NT scheduler features
guest
Pages are backed by private Improved CPU resource
virtual memory on the host. Reduces number of memory tracking/management
intercepts generated by the
guest. Root schedules all VP-backing
threads
IOMMU Based GPU Isolation (1803)
Host
Guest VRAM Address VRAM
A
Successful hardware attack result in
Guest Physical System
Address
VRAM and the portion of system
memory visible to the GPU to be
compromised…
But ntos, pool, process regular
memory, etc… is safe.
Guest RAM
B IOMMU
VidMm (through IOMMU) Limit GPU
accessible system memory to only pages
GPU Page Table under direct the GPU should have access to.
Host VidMm Control
Violations of promises are
observable.
Tampering is a risk to Windows
• Protected Process are used • Kernel and User mode • Key boot properties • Patch Guard and Hyper Guard
to prevent tampering of key code integrity policy are measured into PCRs effective effectively monitor
security components targeted by memory (DHA) TCB tampering
• LSASS, Defender, and corruption issues • No easy way to • Not extensible for consumers
Defender ATP all use PPL • EPROCESS security consume and extend
properties
Goal: Tamper evident Windows
System Guard Runtime Attestation
Attest to report authenticity
Hosted (spoofing, replay)
ATP Cloud Attestation
VTL-0 VTL-1
Octagon
assertions
Critical
ATP Defender
Continuous integrity
Services
System Guard API
Execution
Enclave Cert
Octagon Enclave
System Guard Runtime Broker Report
(Assertion Engine)
Communication Assistant Assertion
Assistant
System Guard Agent Notifications
Hardware backed runtime attestation
Improve transparency: Device Security Features
Windows security promises are increasing
10 S is the best expression of Windows security
Aspirational security promises are the guiding principles for security investments
https://aka.ms/cesecurityopenjobs
https://aka.ms/bugbounty https://aka.ms/wdgsecurityjobs
