Architecture Support for Trust & Security in Cloud
HyperCoffer
CFIMon
Challenges Ascribed to the Cloud [IDC’08]
7 Threats of Cloud Security [Gartner’08] • Privileged operator access • Regulatory compliance Regulatory compliance • Data location • Data segregation • Recovery • Investigative support • Long‐term viability
Security Challenges: Inside Attacks
..., peeking in on emails, chats and Google Talk call logs for several months …
Security Challenges: Outside Attacks • Attacks on Sony in 2011 – Play Station Network was hacked and service was unavailable for more than 23 days than 23 days – About 100 million users’ account/password leaked
• Account/Password Leakage in China – On 2011‐12‐21, over 6 million account/password of CSDN leak to the Internet – Followed by Kaixin.com, Renren.com, Sina.com, etc. – CNCERT reported 26 database including 280 million account/password leaked to the public
Security Challenges: Current Situation • In Amazon’s User Agreement:
We strive to keep your content secure, but cannot guarantee what we will be successful at doing so, …
Security Challenges of Cloud Computing • 1. Inside Attacks – Cloud operators are untrustable – Malicious hypervisor / hardware M li i h i /h d
• 2. Outside Attacks – Attack the whole software stack
HyperCoffer
• Architecture Support – Solution‐1: Minimize the TCB (Trusted Computing Base) – Solution‐2: Monitor CFI by PMU (Performance Measuring Unit)
CFIMon
HyperCoffer
Solution‐1: Minimizing TCB
Security Challenges: Growing TCB 10000
Control VM
TCB Size of Xen System
Xen 2.0 Xen 3.0 Xen 4.0
8000 6000
Tools Kernel
4000
Guest VM
KLOCs
2000 VMM
0
VMM
Dom0 Tools Kernel [Colp, SOSP’11]
TCB
Trusted Computing Base
• The TCB is growing to 9 Million LOCs by 2011 • One point of penetration leads to full compromise • 32 security issues are found in Xen and 35 in VMWare by Oct 2010. [CVE’10] • The virtualization stack should be untrusted
Related Work • Software: Nested Virtualization – – – – –
Add one thin layer below the hypervisor E.g. CloudVisor E Cl dVi [SOSP’11] + Backward compatibility on SW + Work directly on commodity HW ‐ Cannot defend physical attack
• Hardware: Architecture Support – – – – – –
Tools Kernel
Guest VM
Nested VMM
CloudVisor
Tools
Guest
VM Secure processor based p Kernel E.g. XOMOS [SOSP’03], SecureME[ICS’11], etc. VMM SW + Further reduce TCB size Other Trusted HW + Can defend physical attack HW HW ‐ Non‐trivial modification on SW & HW ‐ Not consider cloud environment, e.g. server consolidation
HyperCoffer: Minimize TCB Trusted
Untrusted
Dom-0
VM-2
Dom-0
Hypervisor
Software Hardware
VM-1
VM-1
VM-2
Hypervisor
CPU
Memory
Bus
Sec-CPU
Memory
Bus
Disk
NIC
Other
Disk
NIC
Other
Traditional System
HyperCoffer System
Reduce TCB to only Secure Processor
Protecting through Secure Processor Dom-0
• Secure Processor – – – –
CPU is the only trusted component Guest’s data is encrypted G t’ d t i t d outside CPU t id CPU Protect both guest OS & applications Against attacks from hardware or hypervisor
• Data Privacy – – – –
All the data in VM is encrypted All the data in VM is encrypted Different VM has different key VM‐keys are saved in‐chip Malicious hypervisor/hardware cannot read VM data
VM-1
VM-2
Hypervisor Sec-CPU
Memory
Bus
Disk
NIC
Other
• Data Integrity – BMT BMT (Bonsai Merkel Tree) (Bonsai Merkel Tree) – Root hash is saved in‐chip – Every memory read will check hash value – Every memory write will update BMT
Challenges • 1. Data sharing between hypervisor and VMs – Selective expose fields of CPU context to the hypervisor – Auxiliary info for instruction emulation (e.g. guest page table) A ili i f f i t ti l ti ( t t bl ) – I/O emulation for both disk and NIC
• 2. Backward compatibility with existing OS – Minimize the cost of deployment
• 3. Supporting arbitrary number of VMs on a chip – Not limited by data structure on the chip
• HyperCoffer – Retaining OS‐transparency with VM‐Shim
Tool
Guest Apps pp
OS
Guest OS
M Manage VM
Managee VM
HyperCoffer Overview Tool
Guest Apps
OS
Guest OS
VM-Shim
Non-root Mode Root Mode
Software
Hardware
Hypervisor
Other HW
CPU
Original x86 Virtualization Architecture
Hypervisor
Other HW
Secure CPU
HyperCoffer Architecture
VM‐Shim Manaage VM
• Interposing Tool
Guest Apps
OS
Guest OS
– Reentry issue when interrupts happen – Keep the guest OS unchanged K th t OS h d
• Interactive Data VM-Shim
Hypervisor yp
Other HW
Secure CPU
– CPU Context, Auxiliary info, I/O buffer – copydecrypt & copyencrypt for sharing
• Security Protection – Protection from the hypervisor – Protection from the guest VM itself – Isolation within VM‐Shims
Summary of HyperCoffer • Hardware Software Mechanism – Secure processor substrate – VM‐Shim mechanism VM Shim mechanism
• Full‐System Protection – Protect both guest OS & applications – Against attacks from hypervisor / hardware
• Backward Compatibility – Run unmodified guest OS – Trivial modification to hypervisor – Multi‐core support
VM
VM
Hypervisor CPU
Mem
Bus
Disk
NIC
Dev
CFIMon
Solution‐2: Monitor CFI by PMU
Motivation: Code Injection Attack • A Typical Buffer Overflow Attack void function(char *str) { char h buf[16]; b f[16] strcpy(buf,str); }
– Inject malicious code in buffer – Overwrite return address to buffer – Once return, the malicious code runs
ebp
• Solutions – RedZone to guard stack – Make data section non‐executable
buf
• New Attacks – Return‐to‐libc & return‐oriented programming
Find code gadgets in existed code base (e.g. libc) P h dd Push address of gadgets on the stack f d t th t k Leverage ‘ret’ to connect code gadgets No code injection
• Solutions – Return‐less kernels – Heuristic means
• New Attacks: Jump‐oriented – Use gadget as dispatcher
Motivation: Why CFI? • The Nature of These Attacks: – Allowing entry to any address in an executable program or library – The control flow integrity (CFI) is violated The control flow integrity (CFI) is violated
• General Solutions to Enforce CFI – Some need binary re‐writing or source re‐compiling – Some need application/OS/Hardware re‐designing – Some have large overhead (3.6X for LIFT and 37X for TaintCheck)
• Challenges – Non‐intrusive general attack detection – Apply to existing applications on commodity hardware
• Observations – Performance counters can be leveraged to monitor CFI
Performance Counter of Intel CPU • PEBS: Precise Performance Counter – Save samples in memory region for batching – Atomic‐freeze: record exact IP address precisely
• BTS: Branch Trace Store – Capture all control transfer events – Also save exact IP in memory region
Completeness Accuracy Efficiency
• LBR: Last Branch Record – Save samples in register stack, only 16 pairs
• Event Filtering Event Filtering – E.g. “do not capture near return branches” – Only available in LBR, not BTS
• Conditional Counting – E.g. “only counting when at user mode”
Samples of Trace 0xff01cb 0 ff01 b -> > 0xff01bb 0xff01c0 -> 0xff01fb … 0xff01cb -> 0xff01bb 0xff01c0 -> 0xff01fb
CFIMon: Offline Analysis • Branch Types – Direct branch: e.g. jnz 0xFF08, call , ret – Indirect branch: e.g. jmp I di t b h j (% ) ll % b (%eax), call %ebx
• Static Analysis – Legal sets: the legal target set for every direct branch – Suitable for direct branches
• Dynamic Training – Training set: all branches in training – Cover both direct and indirect branches – Context‐based rule generating (current work)
Code injection R t Return‐to‐libc t lib Ret‐oriented Jump‐oriented All above can be defended
• Performance Evaluation Performance Evaluation – Small overhead for I/O‐bound server applications – The overhead of CPU‐bound applications is still large • Most overhead comes from the BTS itself
Summary of CFIMon • CFIMon – Detect a wide range of attacks to CFI – Leverage existing hardware features L i ti h d f t
• Implications on HW Enhancements – Event filtering for BTS – Co‐existing multiple counters for security – Precise linear address information of memory stores
• Future Work – Reduce the performance overhead of PMU – Non‐control data attacks
Thanks
HyperCoffer
CFIMon
CFIMon Architecture Offline Analysis • Static analysis: get legal target sets for each branch • Dynamic training: get training set of all branches
Online Detection • Apply Apply rules from rules from offline analysis • Handle special cases • Dynamic learning • BTS: generate all branches of app • Collect periodically & when critical
