Strong User Binding to VMs for Secure Management

UVBond: Strong User Binding to VMs for Secure Remote Management in Semi-Trusted Clouds Keisuke Inokuchi and Kenichi Kourai Kyushu Institute of Technology, Japan

2 Remote Management in Clouds IaaS clouds provide users with virtual machines (VMs) Provide remote management of VMs Users manage their VMs via the management servers Connect to the server and manipulate VMs E.g., boot, shutdown, migration, and out-of-band remote management management server VM user cloud

3 Untrusted Cloud Operators Not all the cloud operators are trusted in semi-trusted clouds 28% of cybercrimes are caused by insiders [PwC'14] 35% of admins have accessed sensitive information [CyberArk'09] Untrusted cloud operators can abuse the management server and its ability management server VM operators

4 Issue 1: Illegal Command Execution Cloud operators can execute arbitrary management commands to VMs Perform out-of-band remote management Access virtual serial consoles and GUI consoles of VMs Perform VM introspection Access the memory, disks, and network of VMs Eavesdrop on and tamper with sensitive information VM illegal command operators

5 Issue 2: VM Redirection Attack Cloud operators can redirect user's commands to malicious VMs Redirect out-of-band remote management Steal login passwords by a malicious login program or a key logger Redirect VM introspection Return fake information even for compromised VMs redirect command management server user's VM malicious VM user

6 The Root Cause The binding of users to their VMs is weak in traditional clouds Cloud operators can access user's VMs Necessary privilege for cloud management Users can access cloud operator's VMs Difficult to distinguish VMs operator's VM user's VM operators user

7 UVBond Strongly bind users to their VMs in the trusted hypervisor Securely boot user's VM in semi-trusted clouds Issue a VM descriptor to the user after the boot Permit only the user to execute commands only to the VM corresponding to the VM descriptor Prevent illegal command execution and VM redirection attacks command management server user's VM malicious VM operators user hypervisor

8 Threat Model The hypervisor are trusted By remote attestation with TPM at boot time By security checks with hardware at runtime Cloud operators are not trusted Abuse privileged components including the management server management server virtual devices VM operators hypervisor

9 VM Boot with UVBond Share a disk encryption key between a user and the hypervisor The hypervisor associates the key with a created VM Boot the VM by decrypting its encrypted disk in the hypervisor Guarantee that user's own VM is booted with the correct disk encrypted disk VM boot management server VM disk encryption key user hypervisor decrypt

10 VM Descriptors Issue a VM descriptor to the user after the boot of a VM The hypervisor associates the descriptor with the VM Securely send the descriptor by encrypting it The user specifies the descriptor on executing commands to his VM The hypervisor permits access to the VM only when the descriptor matches the VM command management server VM VM descriptor VM user descriptor hypervisor

11 VM Migration with UVBond Obtain the disk encryption key from the hypervisor Transfer it to the destination host It is encrypted by the public key of the destination hypervisor Re-register the key to the destination hypervisor The key is decrypted by the private key of that hypervisor Users can use the same VM descriptor VM migrate management server VM VM transfer user hypervisor hypervisor

12 Semantic Gap The hypervisor cannot directly recognize user's high-level commands It can recognize only low-level hypercalls issued by commands Each command usually consists of a set of hypercalls Difficult to associate a VM descriptor only with correct hypercalls The hypervisor could not detect hypercall injection VM descriptor command VM hypercall user hypervisor

13 Hypercall Automaton Identify each command by a sequence of hypercalls Different commands may have the same sequence The same sequence means the same effect on VM management Use a finite state automaton that accepts all the possible sequences for each command One command can have various sequences command pause unpause mem-set shutdown destroy save state transition 9 8 xen_version memory_op memory_op 10 15 10 12 20 10 15 9 13 21 sysctl sysctl 1 9 10 11 12 8 domctl domctl x8 memory_op sysctl 13 14 15

14 Automaton-based Permission Permit access to a VM as long as a hypercall sequence is not rejected by a hypercall automaton A user specifies a hypercall automaton as well as a VM descriptor Allow even cloud operators to execute some of the commands without a VM descriptor Trade-off between ease of management and security VM descriptor VM command hypercall automaton hypercall user hypervisor hypercall automaton

15 Simultaneous Command Execution Hypercalls can be simultaneously issued by multiple commands Need to apply a different hypercall automaton for each command Handle a hypercall sequence per command Distinguish commands using processes executing them Identify each process by its page tables [Jones+ ATC'06] page table 1 page table 2 command 1 command 2 hypervisor hypercall automaton 1 hypercall automaton 2

16 Preventing Information Leakage Secure out-of-band remote management The hypervisor has to encrypt I/O data [Egawa+ CloudCom'12] UVBond prevents its key from being registered to a malicious VM Secure VM introspection UVBond allows only a user to map his VM's memory The hypervisor has to encrypt the memory data [Kourai+ CLOUD'16] en/decrypt encrypted I/O management server VM encrypted memory data remote host hypervisor

17 Encryption of Para-virtualized Disk I/O Paravirtual disk drivers are often used for performance Consist of front-end and back-end drivers Share grant pages between them for I/O buffers The hypervisor en/decrypts grant pages Monitor the communication between the two drivers Even cloud operators can read decrypted data in grant pages VM encrypted disk backend driver grant page frontend driver en/decrypt hypervisor

18 Duplication of Grant Pages The hypervisor duplicates grant pages Only a guest grant page can hold decrypted data A shadow grant page always holds encrypted data The hypervisor synchronizes the two types of grant pages Encrypt data in a guest grant page and stores it to a shadow one Decrypt data in a shadow grant page and stores it to a guest one VM decrypt guest grant page shadow grant page encrypted disk backend driver frontend driver encrypt hypervisor

19 Using AES-NI in the Hypervisor Using XMM registers causes a hardware exception The hypervisor defers the restoration of XMM registers on CPU scheduling Temporarily disable a hardware exception Save XMM registers before the use Restore them after the use UVBond hypervisor 1. save 3. restore 2. use XMM registers

20 Experiments We conducted experiments to confirm the effectiveness of UVBond Investigate the execution of management commands Measure the boot and migration time Examine disk I/O performance vCPU: 2 Memory: 2 GB HDD: 20 GB VM CPU: Intel Xeon E3-1290 v2 Memory: 8 GB HDD: 1 TB Gigabit Ethernet

21 Command Execution with Hypercall Automata We executed commands with various VM descriptors and hypercall automata The command execution succeeded only when both were correct We measured the execution time of commands The overhead was 4 ms for short-time commands Negligible overhead for long-time ones long-time commands 15 12 short-time commands 10 time (ms) 10 time (sec) 8 vanilla UVBond 6 5 4 2 0 0 pause unpause mem-set memset (2nd) shutdown (1st) destroy save

22 Performance of a VM Boot We measured the time from the execution of the create command to OS boot-up With/without the page cache for VM's disk The boot time was 6 sec longer in UVBond Due to the overhead of additional operations including encryption 25 20 time (sec) 15 vanilla UVBond 10 5 0 w/o page cache w/ page cache

23 Performance of VM Migration Migration time We measured the execution time of the migrate command UVBond was 1.4 sec longer than vanilla Xen Downtime We measured the time during which the VM stopped UVBond was only 50 ms longer 20 0.6 migration time downtime (sec) 15 0.4 vanilla UVBond (sec) 10 0.2 5 0 0

24 Disk I/O Performance We measured the throughput and the latency using fio Compared with dm-crypt inside a VM The performance degradation was less than 10% Thanks to AES-NI Comparable to dm-crypt 200 25 vanilla throughput (MB/s) 20 150 latency (ms) dm-crypt 15 100 10 UVBond 50 5 UVBond (no AES-NI) 0 0 sequential read sequential write random read random write sequential read sequential write random read random write

25 Related Work Self-service cloud [Butt+ CCS'12][Butt+ SoCC'14] User's VMs can be securely managed in his own privileged VM The TCB is quite large BitVisor [Shinagawa+ VEE'09] Encrypt the disk of a VM using a parapass-through driver Support only fully virtualized OSes System-call automata [Hofmeyr+ Comp.Sec.'98] Detect intrusion on the basis of a sequence of system calls Hypercall automata are its application to the hypervisor

26 Conclusion We proposed UVBond for providing strong user binding to VMs in semi-trusted clouds Boot user's VM by decrypting its encrypted disk inside the hypervisor Securely execute management commands to his VM With a VM descriptor and hypercall automata Prevent illegal command execution and VM redirection attacks Future work Apply UVBond to large cloud management systems, e.g., OpenStack Need to extract commands and create their hypercall automata Need to modify the web interface and API