CPU SIDECHANNELS VS VIRTUALIZATION MALWARE THE GOOD THE

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 u. Arch side-channel • Demo • Conclusion 2 9/16/2020

RSB BASED μARCH SIDE-CHANNEL 3 9/16/2020

μARCH SIDE-CHANNELS • • Cache based side-channel attacks • 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) 4 (Simple) Branch Prediction Analysis (BPA) Instruction cache analysis Shared FU attack (shared multiplier in SMT capable CPU) Information about the secret leaks through this CPU resource and can be measured by the spy to recover the key 9/16/2020

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 9/16/2020

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 9/16/2020

FILLING RSB WITH SPY’S RET’urns • Crypto thread executes squareand-multiply modular exponentiation or Montgomery modular multiplication (MMM) • Let’s take a look at this Montgomery reduction: crypto executes // Montgomery modular reduction crypto_montgomery_reduction {. . // End Reduction step if( crypto_cmp(a, N) >= 0 ) { crypto_sub(a, a, N); }. . } 7 9/16/2020 call call call call func 15 func 14 func 13 func 12 func 11 func 10 func 9 func 8 func 7 func 6 func 5 func 4 func 3 func 2 func 1 func 0 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 9/16/2020 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 9 9/16/2020 rdtsc ret ; ret ; ret ; ret ; rdtsc RSB func 15 func 14 func 13 func 12 func 11 func 10 func 9 func 8 func 7 func 6 func 5 func 4 func 3 func 2 func 1 func 0

HYPER-CHANNEL: USING RSB BASED μARCH SIDE-CHANNEL TO SPY ON HYPERVISOR 10 9/16/2020

OOPS. LET’S DO IT AGAIN 1. Spy populates #VMEXIT CPUID call func 15 RSB by executing call func 14 call func 13 16 nested CALL’s call func 12 Executes CPUID call func 11 call func 10 or any other call func 9 instruction that call func 8 causes #VMEXIT call func 7 call func 6 • If OS is in non-root call func 5 (guest) mode then call func 4 CPUID is trapped by call func 3 hypervisor call func 2 call func 1 call func 0 2. 11 9/16/2020 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_subfunc 1: call vmexit_subfunc 11 vmexit_subfunc: call vmexit_subfunc 1 VMExit_Handler: call vmexit_subfunc 12 9/16/2020

SPY OBSERVES RSB MISSPREDICTIONS 4. rdtsc After #VMEXIT spy ret ; executes 16 RET’urns ret ; – RSB hit: < 3 clk cycles ret ; – RSB miss penalty: 10 -15 ret ; clk cycles 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 ; rdtsc 5. 13 9/16/2020 RSB func 15 func 14 func 13 func 12 func 11 func 10 func 9 func 8 func 7 func 6 func 5 func 4 func 3 func 2 func 1 func 0

CLOSER LOOK AT THE RSB SPY. . func 15() { cpuid ; #VMEXIT on VT rdtsc ; start measurement ret ; start 16 returns } func 14() { call func 15 ret }. . func 0() { call func 1 ret } 14 9/16/2020 spy() { cli call func 0 rdtsc ; end measurement sti }

DEMO: HYPER-CHANNEL DETECTOR 15 9/16/2020

DEMO: HYPER-CHANNEL 16 9/16/2020

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 u. Arch side-channel using TLB’s 17 9/16/2020

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 9/16/2020

CONCLUSION • • Side-channels are good. . • 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 Yeah, I know. . this conclusion sucks 9/16/2020

PLUG: Deep. Watch • Deep. Watch 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 9/16/2020

THANK YOU !! QUESTIONS ? ? • Thanks to researchers of virtualization rootkits, their detection methods, and u. Arch side-channel analysis • I’d also like to acknowledge Sagar Dalvi and Mark Davis from Intel secure@intel. com http: //www. intel. com/security 21 9/16/2020

22 9/16/2020

REFERENCES • Nate Lawson, Peter Ferrie, Thomas Ptacek: http: //www. matasano. com/log/930/side-channel-detection-attacks-against-unauthorizedhypervisors/ 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/attacks 2. 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/hotos 07/vmm_detection_hotos 07. pdf, http: //x 86 vmm. 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 9/16/2020