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

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

• Yuriy Bulygin
• Security Center of Excellence
• Intel Corporation

2
AGENDA

• RSB based micro-architectural side-channel
• Hyper-channel detecting hypervisor with uArch
  side-channel
• Demo
• Conclusion

3
RSB BASED µARCH SIDE-CHANNEL
4
µ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 spys 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

5
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
  its 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 CALLs if
  RSB is full the oldest return address is
  overwritten
• Mispredict penalty if its later determined that
  it doesnt match return address popped from
  program stack

6
USING RSB TO SPY ON CRYPTO CODE

• Spy thread executes 16 nested CALL instructions
  to fill RSB with spys 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 spys
  return addresses replaced with cryptos 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

7
FILLING RSB WITH SPYS RETurns
? crypto executes
RSB

• Crypto thread executes square-and-multiply
  modular exponentiation or Montgomery modular
  multiplication (MMM)
• Lets take a look at this Montgomery reduction

call func15 ? call func14 ? call func13 ? call
func12 ? call func11 ? call func10 ? call func9
? call func8 ? call func7 ? call func6 ? call
func5 ? call func4 ? call func3 ? call func2
? call func1 ? call func0 ?







// Montgomery modular reduction crypto_montgomery_
reduction .. // End Reduction step if(
crypto_cmp(a, N) gt 0 ) crypto_sub(a,
a, N) ..









8
CRYPTO CORRUPTS SPYS RSB DEPENDING ON THE SECRET
RSB

1. No End Reduction (A lt N)

if( crypto_cmp(a, N) gt 0 )
crypto_sub(a, a, N)


The rest of spys return addresses are not
corrupted

1. End Reduction is carried out (A N)

if( crypto_cmp(a, N) gt 0 )
crypto_sub(a, a, N)


crypto_sub replaces additional entries



9
SPY OBSERVES RSB MISSPREDICTIONS
RSB
rdtsc

• 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 with ER
  step

ret func15 ? ret func14 ? ret func13 ? ret
func12 ? ret func11 ? ret func10 ? ret
func9 ? ret func8 ? ret func7 ? ret
func6 ? ret func5 ? ret func4 ? ret
func3 ? ret func2 ? ret func1 ? ret
func0 ?













RSB miss ? RSB miss ? RSB miss ? RSB miss ?



rdtsc
10
HYPER-CHANNELUSING RSB BASED µARCH SIDE-CHANNEL
TO SPY ON HYPERVISOR
11
OOPS. LETS DO IT AGAIN
RSB
VMEXIT ? CPUID

• Spy populates RSB by executing 16 nested CALLs
• Executes CPUID or any other instruction that
  causes VMEXIT
• If OS is in non-root (guest) mode then CPUID is
  trapped by hypervisor

call func15 ? call func14 ? call func13 ? call
func12 ? call func11 ? call func10 ? call func9
? call func8 ? call func7 ? call func6 ? call
func5 ? call func4 ? call func3 ? call func2
? call func1 ? call func0 ?
















12
HYPERVISOR CORUPTS SPY RSB CONTENTS
RSB

• VMEXIT handler is likely to corrupt 1 or more
  spys 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 ?



13
SPY OBSERVES RSB MISSPREDICTIONS
RSB
rdtsc

• After VMEXIT spy executes 16 RETurns
• RSB hit lt 3 clk cycles
• RSB miss penalty 10-15 clk cycles
• Experiment
• Clear 83 cycles
• Rootkit-ed 123 cycles
• Can be gt300 cycles if VMEXIT handler slightly
  modified

ret func15 ? ret func14 ? ret func13 ? ret
func12 ? ret func11 ? ret func10 ? ret
func9 ? ret func8 ? ret func7 ? ret
func6 ? ret func5 ? ret func4 ? ret
func3 ? ret func2 ? ret func1 ? ret
func0 ?














RSB miss ? RSB miss ? RSB miss ?


rdtsc
14
CLOSER LOOK AT THE RSB SPY ..
spy() cli call func0 rdtsc end
measurement sti

• func15()
• cpuid VMEXIT on VT
• rdtsc start measurement
• ret start 16 returns
• func14()
• call func15
• ret
• ..
• func0()
• call func1
• ret

15
DEMO HYPER-CHANNEL DETECTOR
16
DEMO HYPER-CHANNEL
17
PROPERTIES

• No false negatives !! A single RSB entry
  corruption is detectable
• Hyper-channel needs to know time taken by 16
  RETs to execute on non-virtualized 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-channels
  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 theres no externally published uArch
  side-channel using TLBs

18
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 !!
• Its 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 its suspicious
  !! Which legitimate VMM calls more than 16 nested
  subroutines ?? shoot it..

19
CONCLUSION

• Side-channels are good..
• Yeah, I know.. this conclusion sucks
• Although many are tired of virtualization
  competition, lets 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 ??

20
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 youll see its demo soon..

21
THANK YOU !! QUESTIONS ??

• Thanks to researchers of virtualization rootkits,
  their detection methods, and uArch side-channel
  analysis
• Id also like to acknowledge Sagar Dalvi and Mark
  Davis from Intel

secure_at_intel.comhttp//www.intel.com/security
22
(No Transcript)
23
REFERENCES

• Nate Lawson, Peter Ferrie, Thomas Ptacek
• http//www.matasano.com/log/930/side-channel-dete
  ction-attacks-against-unauthorized-hypervisors/
• https//www.blackhat.com/presentations/bh-usa-07/
  Ptacek_Goldsmith_and_Lawson/Presentation/bh-usa-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/B
  H-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/4245200
  8/detection.rar.html
• Tal Garfinkel, Keith Adams, Andrew Warfield,
  Jason Franklin
• http//www.cs.cmu.edu/jfrankli/hotos07/vmm_detec
  tion_hotos07.pdf,
• http//x86vmm.blogspot.com/2007/07/bluepill-detec
  tion-in-two-easy-steps.html
• Michael Myers, Stephen Youndt
• http//www.crucialsecurity.com//index.php?option
  com_contenttaskviewid94Itemid136/
• bugcheck vrdtsc