Using CPU side-channels to detect hypervisors
Download
Report
Transcript Using CPU side-channels to detect hypervisors
CPU SIDE-CHANNELS VS. VIRTUALIZATION
MALWARE: THE GOOD, THE BAD, OR THE UGLY
Yuriy Bulygin
Security Center of Excellence
Intel Corporation
AGENDA
• RSB based micro-architectural side-channel
• Hyper-channel: detecting hypervisor with uArch
side-channel
• Demo
• Conclusion
2
7/18/2015
RSB BASED μARCH SIDE-CHANNEL
3
7/18/2015
μARCH SIDE-CHANNELS
•
•
•
•
Cache based side-channel attacks
(Simple) Branch Prediction Analysis (BPA)
Instruction cache analysis
Shared FU attack (shared multiplier in SMT capable CPU)
• Crypto + Spy threads (software or hardware) share some CPU
resource
• Spy puts the shared resource in a known state and monitors if
and how it was corrupted by crypto
• Crypto may corrupt spy’s state depending on the secret (key)
• Information about the secret leaks through this CPU resource
and can be measured by the spy to recover the key
4
7/18/2015
RETURN STACK BUFFER (RSB)
• Internal hardware “stack” in CPU
– Typically simple push/pop stack structure with 16 entries
– May be more complicated that simple stack on modern CPUs
• Predicts target address of RET instruction before it’s
available from memory
– CALL instruction drives next linear IP (return address) into
the RSB
– target address of RET instruction is derived from the
topmost RSB entry
– RSB is circular buffer with respect to CALL’s: if RSB is full
the oldest return address is overwritten
• Mispredict penalty if it’s later determined that it
doesn’t match return address popped from program
stack
5
7/18/2015
USING RSB TO SPY ON CRYPTO CODE
• Spy thread executes 16 nested CALL instructions to fill RSB
with spy’s return addresses
• Crypto thread executes code (e.g. ER step in Montgomery
modular reduction algorithm)
• Spy thread then executes 16 RET instructions and measures
time taken to execute them
–
Or directly measures “number of RSB misses” performance counter
• Spy observes increased time due to RSB mispredictions
corresponding to one or more spy’s return addresses replaced
with crypto’s return addresses
• What if crypto implementation replaced different # of RSB
entries depending on key bit or result of mod multiplication ??
• Spy would be able to differentiate key bit value based on # of
RSB mispredictions
6
7/18/2015
FILLING RSB WITH SPY’S RET’urns
Crypto thread executes square- crypto executes
call func15
and-multiply modular
call func14
exponentiation or Montgomery
call func13
modular multiplication (MMM)
call func12
• Let’s take a look at this
call func11
Montgomery reduction:
call func10
call func9
// Montgomery modular reduction
call func8
crypto_montgomery_reduction {
call func7
..
call func6
// End Reduction step
call func5
if( crypto_cmp(a, N) >= 0 )
call func4
{
call func3
crypto_sub(a, a, N);
call func2
}
call func1
..
call func0
}
•
7
7/18/2015
RSB
CRYPTO CORRUPTS SPY’S RSB DEPENDING
ON THE SECRET
RSB
1. No End Reduction (A < N)
if( crypto_cmp(a, N) >= 0 )
{
crypto_sub(a, a, N);
}
The rest of spy’s
return addresses
are not corrupted
2. End Reduction is carried out (A ≥ N)
if( crypto_cmp(a, N) >= 0 )
{
crypto_sub(a, a, N);
}
8
7/18/2015
crypto_sub replaces
additional entries
SPY OBSERVES RSB MISSPREDICTIONS
Spy can distinguish if
crypto executed:
• crypto_cmp only (1 RSB
miss): MMM w/o End
Reduction
or
• crypto_cmp/crypto_sub
(4 RSB misses): MMM
RSB miss
with ER step
RSB miss
RSB miss
RSB miss
9
7/18/2015
rdtsc
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
ret ;
rdtsc
RSB
func15
func14
func13
func12
func11
func10
func9
func8
func7
func6
func5
func4
func3
func2
func1
func0
HYPER-CHANNEL:
USING RSB BASED μARCH SIDE-CHANNEL
TO SPY ON HYPERVISOR
10
7/18/2015
OOPS. LET’S DO IT AGAIN
1.Spy populates
#VMEXIT CPUID
call func15
RSB by executing
call func14
call func13
16 nested CALL’s
call func12
Executes CPUID
call func11
call func10
or any other
call func9
instruction that
call func8
causes #VMEXIT
call func7
call func6
• If OS is in non-root
call func5
(guest) mode then
call func4
CPUID is trapped by
call func3
hypervisor
call func2
call func1
call func0
2.
11
7/18/2015
RSB
HYPERVISOR CORUPTS SPY RSB CONTENTS
3.#VMEXIT handler is likely
RSB
to “corrupt” 1 or more
spy’s RSB entries replacing
them with its own entries
• It enough for #VMEXIT
handler to make 1 CALL to
subfunction
13 hyper-channel
return addresses
are not corrupted
vmexit_subfunc1: call vmexit_subfunc11
vmexit_subfunc: call vmexit_subfunc1
VMExit_Handler: call vmexit_subfunc
12
7/18/2015
SPY OBSERVES RSB MISSPREDICTIONS
4.
rdtsc
After #VMEXIT spy
ret ;
executes 16 RET’urns
ret ;
ret ;
– RSB hit: < 3 clk cycles
ret ;
– RSB miss penalty: 10-15
ret ;
clk cycles
ret ;
ret ;
Experiment:
ret ;
– Clear: 83 cycles
ret ;
– Rootkit-ed: 123 cycles
ret ;
– Can be >300 cycles if
ret ;
#VMEXIT handler slightly
ret ;
modified
ret ;
RSB miss ret ;
RSB miss ret ;
RSB miss ret ;
rdtsc
5.
13
7/18/2015
RSB
func15
func14
func13
func12
func11
func10
func9
func8
func7
func6
func5
func4
func3
func2
func1
func0
CLOSER LOOK AT THE RSB SPY ..
func15() {
cpuid ; #VMEXIT on VT
rdtsc ; start measurement
ret
; start 16 returns
}
func14() {
call func15
ret
}
..
func0() {
call func1
ret
}
14
7/18/2015
spy() {
cli
call func0
rdtsc ; end measurement
sti
}
DEMO: HYPER-CHANNEL DETECTOR
15
7/18/2015
DEMO: HYPER-CHANNEL
16
7/18/2015
PROPERTIES
•
No false negatives !! A single RSB entry corruption is detectable
– Hyper-channel needs to know time taken by 16 RET’s to execute on nonvirtualized OS (noticed 100 in command-line ??)
– “# of RSB misses” perf. counter is always 0 on non-virtualized OS !!
•
The RSB side-channel detection is probabilistic
– RSB can be flushed due to multiple events
– So the detector needs to make multiple measurements to decrease
likehood of the false positive
– Experimental probability of a false positive is ~ 1/1000 (RSB was flushed
during hyper-channel’s measurement)
– Make as few as 10 measurements
•
#VMEXIT behavior related to RSB depends on the core
– RSB may be entirely flushed by #VMEXIT microcode
– This is easily detectable but detector cannot tell anything about the
hypervisor
•
Timing and TLB profiling are also side-channels
– But there’s no externally published uArch side-channel using TLB’s
17
7/18/2015
EVADING HYPER-CHANNEL
• Hypervisor may not make any calls inside VMExit
handler
– In this case hyper-channel detector will be useless
– But this is a painful restriction !!
– It’s similar to requiring crypto implementations to not make
any key-dependant calls (what about recursive Karatsuba
sqr/mul ??)
• Clearly malicious hypervisor can masquerade
legitimate VMM by making the same # of nested
calls
– It cannot evict all 16 entries as it’s suspicious !! Which
legitimate VMM calls more than 16 nested subroutines ??
shoot it..
18
7/18/2015
CONCLUSION
• Side-channels are good..
• Yeah, I know.. this conclusion sucks
• Although many are tired of virtualization competition, let’s
respect awesome research in virtualization rootkits and their
detection
• With widespread of HW virtualization, exploits targeting
legitimate hypervisors may become as common as OS kernel
exploits are now
• We can detect that OS is virtualized, probably can detect
malicious hypervisor by all known heuristics
• So what ?? Can we remove it ??
19
7/18/2015
PLUG: DeepWatch
•
DeepWatch is a Proof of Concept hardware
based detector of virtualization malware
•
that uses embedded microcontroller in
chipset
•
to detect malicious hypervisor and remove
it from the system
•
I hope you’ll see its demo soon..
20
7/18/2015
THANK YOU !! QUESTIONS ??
• Thanks to researchers of virtualization rootkits,
their detection methods, and uArch side-channel
analysis
• I’d also like to acknowledge Sagar Dalvi and Mark
Davis from Intel
[email protected]
http://www.intel.com/security
21
7/18/2015
REFERENCES
•
Nate Lawson, Peter Ferrie, Thomas Ptacek:
http://www.matasano.com/log/930/side-channel-detection-attacks-against-unauthorized-hypervisors/
https://www.blackhat.com/presentations/bh-usa-07/Ptacek_Goldsmith_and_Lawson/Presentation/bhusa-07-ptacek_goldsmith_and_lawson.pdf
http://www.matasano.com/log/
•
Joanna Rutkowska, Alexander Tereshkin:
http://bluepillproject.org
http://www.invisiblethingslab.com
•
Dino A. Dai Zovi:
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Zovi.pdf
•
Peter Ferrie. Attacks on More Virtual Machine Emulators:
http://pferrie.tripod.com/papers/attacks2.pdf
•
•
Edgar Barbosa: http://rapidshare.com/files/42452008/detection.rar.html
Tal Garfinkel, Keith Adams, Andrew Warfield, Jason Franklin:
http://www.cs.cmu.edu/~jfrankli/hotos07/vmm_detection_hotos07.pdf,
http://x86vmm.blogspot.com/2007/07/bluepill-detection-in-two-easy-steps.html
•
Michael Myers, Stephen Youndt:
http://www.crucialsecurity.com//index.php?option=com_content&task=view&id=94&Itemid=136/
•
23
bugcheck: vrdtsc
7/18/2015