CPU SIDE-CHANNELS VS. VIRTUALIZATION MALWARE: THE GOOD, THE BAD, OR

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 12/06/22

RSB BASED μARCH SIDE-CHANNEL 3 12/06/22

μ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 12/06/22

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 12/06/22

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 12/06/22

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 12/06/22 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 12/06/22 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 12/06/22 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 12/06/22

OOPS. LET’S DO IT AGAIN 1.Spy populates #VMEXIT CPUID call func15 RSB by executing call func14 16 nested CALL’s call func13 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 12/06/22 RSB

HYPERVISOR CORUPTS SPY RSB CONTENTS RSB 3.#VMEXIT handler is likely to “corrupt” 1 or more spy’s RSB entries replacing them with its own entries It enough for #VMEXIT handler 13 hyper-channel to make 1 CALL to subfunction return addresses are not corrupted 12 12/06/22 vmexit subfunc1: call vmexit subfunc11 vmexit subfunc: call vmexit subfunc1 VMExit Handler: call vmexit subfunc

SPY OBSERVES RSB MISSPREDICTIONS 4. rdtsc After #VMEXIT spy ret ; executes 16 RET’urns ret ; – RSB hit: 3 clk cycles ret ; ret ; – RSB miss penalty: 10-15 clk ret ; 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 12/06/22 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 12/06/22 spy() { cli call func0 rdtsc ; end measurement sti }

DEMO: HYPER-CHANNEL DETECTOR 15 12/06/22

DEMO: HYPER-CHANNEL 16 12/06/22

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 12/06/22

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 12/06/22

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 12/06/22

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 12/06/22

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 12/06/22

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 12/06/22