Virtualization Technologies and Cloud
`Security: Advantages, Issues,
`and Perspectives
`
`Roberto Di Pietrol(®) and Flavio Lombardi2
`
`1 Information and Computing Technology Division, College of Science
`and Engineering, Hamad Bin Khalifa University, Doha, Qatar
`rdipietro@hbku.edu.qa
`2 Istituto per le Applicazioni del Calcolo, Consiglio Nazionale delle Ricerche,
`Rome, Italy
`flavio.lombardi@cnr.it
`
`Abstract. Virtualization technologies allow multiple tenants to share
`physical resources with a degree of security and isolation that cannot be
`guaranteed by mere containerization. Further, virtualization allows pro-
`tected transparent introspection of Virtual Machine activity and content,
`thus supporting additional control and monitoring. These features pro-
`vide an explanation, although partial, of why virtualization has been an
`enabler for the flourishing of cloud services. Nevertheless, security and
`privacy issues are still present in virtualization technology and hence
`in Cloud platforms. As an example, even hardware virtualization protec-
`tion/isolation is far from being perfect and uncircumventable, as recently
`discovered vulnerabilities show. The objective of this paper is to shed
`light on current virtualization technology and its evolution from the point
`of view of security, having as an objective its applications to the Cloud
`setting.
`
`Keywords: Virtualization • Security • Cloud
`
`1
`
`Introduction
`
`The advances in virtualization technology of the past decade have rendered the
`Cloud approach feasible and convenient. Nevertheless, the main limitation of vir-
`tual machines is that they were born as a means to easily migrate from physically
`deployed services to more compact and manageable images. In fact, each and
`every VM runs its own full operating system together with the various libraries
`required by the application (see Fig. 1) [35]. Such an approach multiplicates the
`usage of RAM, CPU, and storage with respect to simply hosting multiple services
`as separate processes on a single piece of bare metal.
`Containerization technology is intended to replace hypervisor and VMs, and
`deploys each application in its own process-like environment running on the
`physical machine on a single operating system [42]. Containers can be provi-
`sioned (and deprovisioned) in a few seconds and make a more efficient usage
`© Springer Nature Switzerland AG 2018
`P. Samarati et al. (Eds.): Jajodia Festschrift, LNCS 11170, pp. 166-185, 2018.
`https://doi.org/10.1007/978-3-030-04834-1_9
`
`WIZ, Inc. EXHIBIT - 1028
`\VIZ, Inc. v. Orca Security LTD.
`
`Virtualization Technologies and Cloud
`Security: Advantages, Issues,
`and Perspectives
`
`Roberto Di Pietro!) and Flavio Lombardi?
`
`' Information and Computing Technology Division, College of Science
`and Engineering, Hamad Bin Khalifa University, Doha, Qatar
`rdipietro@hbku.edu.qga
`2 Istituto per le Applicazioni del Calcolo, Consiglio Nazionale delle Ricerche,
`Rome, Italy
`flavio.lombardi@cnr.it
`
`Abstract. Virtualization technologies allow multiple tenants to share
`physical resources with a degree of security and isolation that cannot be
`guaranteed by mere containerization. Further, virtualization allows pro-
`tected transparent introspection of Virtual Machine activity and content,
`thus supporting additional control and monitoring. These features pro-
`vide an explanation, although partial, of why virtualization has been an
`enabler for the flourishing of cloud services. Nevertheless, security and
`privacy issues are still present in virtualization technology and hence
`in Cloud platforms. As an example, even hardware virtualization protec-
`tion/isolation is far from being perfect and uncircumventable, as recently
`discovered vulnerabilities show. The objective of this paper is to shed
`light on current virtualization technology and its evolution from the point
`of view of security, having as an objective its applications to the Cloud
`setting.
`
`Keywords: Virtualization - Security - Cloud
`
`1
`
`Introduction
`
`The advances in virtualization technology of the past decade have rendered the
`Cloud approach feasible and convenient. Nevertheless, the main limitation of vir-
`tual machines is that they were born as a means to easily migrate from physically
`deployed services to more compact and manageable images. In fact, each and
`every VM runs its own full operating system together with the various libraries
`required by the application (see Fig. 1) [35]. Such an approach multiplicates the
`usage of RAM, CPU, and storage with respect to simply hosting multiple services
`as separate processes on a single piece of bare metal.
`Containerization technology is intended to replace hypervisor and VMs, and
`deploys each application in its own process-like environment running on the
`physical machine on a single operating system [42]. Containers can be provi-
`sioned (and deprovisioned) in a few seconds and make a more efficient usage
`
`© Springer Nature Switzerland AG 2018
`P. Samarati et al. (Eds.): Jajodia Festschrift, LNCS 11170, pp. 166-185, 2018.
`https://doi.org/10.1007/978-3-030-04834-1_9
`
`WIZ, Inc. EXHIBIT - 1028
`WIZ, Inc. v. Orca Security LTD. - IPR2024-00220
`
`WIZ, Inc. EXHIBIT - 1028
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`Virtualization Technologies and Cloud Security
`
`167
`
`of resources, achieving a much higher application density (orders of magnitude
`[37]) than virtualization. This renders containers much more convenient than
`virtual machines.
`Nevertheless, as we will show along this paper, virtualization is not on a
`dead path. In fact, virtual machines provide additional security mechanisms
`and isolation benefits in many application scenarios that are often worth the
`additional resource usage [28,39].
`A virtualization environment generally consists of three core components: an
`hypervisor or Virtual Machine Manager (also VMM in the following), manage-
`ment tools, and Virtual Machines (VMs). In particular, the infrastructure-as-
`a-service (IaaS) Cloud layer directly leverages and exposes powerful virtualiza-
`tion technologies and resources to a remote user [3]. Nevertheless, virtualization
`technologies also introduce additional security concerns. The size of the attack
`surface for the virtualization approach is directly proportional to the amount of
`emulated physical resource or functionality that must be provided in software.
`As regards containers, they can leverage all services offered by the host OS,
`so the issue here is to enforce effective security and isolation among processes.
`This is actually more difficult to do, since OSes have not been designed with
`this in mind. Further, the partitioning/virtualization modes and ISAsi of recent
`CPU and GPU cannot be used by containers, as they are inherently part of vir-
`tualization and introduce the actual performance penalties of traditional VMs.
`Unikernels can be considered an alternative to both containerization and virtu-
`alization. They maintain some of the benefits of other approaches (lightweight
`and isolated) but introduce further issues such as manageability, monitoring and
`reliability.
`In this paper, we survey various aspects of virtualization, analyze their impact
`on security, and discuss future perspectives. In particular, we provide technol-
`ogy background for most widespread virtualization tools in order to highlight
`features, advantages and potential security flaws, with a focus on their applica-
`tion to Cloud. Further, discussions and comparisons with containerization and
`unikernel approaches are introduced throughout the paper.
`The sequel of this paper is organized as follows: a technology background is
`provided in Sect. 2; most relevant virtualization security issues are introduced in
`Sect. 3; virtualization-based security approaches are presented in Sect. 4; novel
`enclave technology is discussed in Sect. 5; virtualization-based use cases, together
`with some future research trends, are presented in Sect. 6; and, finally, conclu-
`sions and hints for future work are given in Sect. 7.
`
`2 Technology Background
`
`Various different virtualization technologies are currently deployed in the Cloud,
`mostly for x86_64 architectures (e.g., Xen, KVM, VMware, VirtualBox, and
`HyperV). Most relevant details on virtualization frameworks and on supporting
`hardware (CPU/GPU) features are given and discussed in the following sections.
`
`1 Instruction Set Architecture(s).
`
`Virtualization Technologies and Cloud Security
`
`167
`
`of resources, achieving a much higher application density (orders of magnitude
`[37]) than virtualization. This renders containers much more convenient than
`virtual machines.
`Nevertheless, as we will show along this paper, virtualization is not on a
`dead path. In fact, virtual machines provide additional security mechanisms
`and isolation benefits in many application scenarios that are often worth the
`additional resource usage [28,39].
`A virtualization environment generally consists of three core components: an
`hypervisor or Virtual Machine Manager (also VMM in the following), manage-
`ment tools, and Virtual Machines (VMs). In particular, the infrastructure-as-
`a-service (laaS) Cloud layer directly leverages and exposes powerful virtualiza-
`tion technologies and resources to a remote user [3]. Nevertheless, virtualization
`technologies also introduce additional security concerns. The size of the attack
`surface for the virtualization approach is directly proportional to the amount of
`emulated physical resource or functionality that must be provided in software.
`As regards containers, they can leverage all services offered by the host OS,
`so the issue here is to enforce effective security and isolation among processes.
`This is actually more difficult to do, since OSes have not been designed with
`this in mind. Further, the partitioning/virtualization modes and ISAs! of recent
`CPU and GPU cannot be used by containers, as they are inherently part of vir-
`tualization and introduce the actual performance penalties of traditional VMs.
`Unikernels can be considered an alternative to both containerization and virtu-
`alization. They maintain some of the benefits of other approaches (lightweight
`and isolated) but introduce further issues such as manageability, monitoring and
`reliability.
`In this paper, we survey various aspects of virtualization, analyze their impact
`on security, and discuss future perspectives. In particular, we provide technol-
`ogy background for most widespread virtualization tools in order to highlight
`features, advantages and potential security flaws, with a focus on their applica-
`tion to Cloud. Further, discussions and comparisons with containerization and
`unikernel approaches are introduced throughout the paper.
`The sequel of this paper is organized as follows: a technology background is
`provided in Sect. 2; most relevant virtualization security issues are introduced in
`Sect. 3; virtualization-based security approaches are presented in Sect. 4; novel
`enclave technology is discussed in Sect. 5; virtualization-based use cases, together
`with some future research trends, are presented in Sect. 6; and, finally, conclu-
`sions and hints for future work are given in Sect. 7.
`
`2
`
`Technology Background
`
`Various different virtualization technologies are currently deployed in the Cloud,
`mostly for x86_64 architectures (e.g., Xen, KVM, VMware, VirtualBox, and
`HyperV). Most relevant details on virtualization frameworks and on supporting
`hardware (CPU/GPU) features are given and discussed in the following sections.
`
`1 Instruction Set Architecture(s).
`
`

`

`168
`
`R. Di Pietro and F. Lombardi
`
`Apps
`
`<S9
`Content
`
`Collaboration
`
`Communication
`
`692227-
`
`3
`
`Runtime
`
`Object
`Storage
`
`Database
`
`Guest OS
`
`Guest Kernel
`
`Hypervisor
`
`HW (CPU/GPU/Disk/Net)
`
`Fig. 1. Cloud layers and virtualization
`
`2.1 Virtualization Frameworks
`
`The essential characteristics of the most widespread virtualization environments
`are summarized in Table 1. It is worth noting that all present hypervisors sup-
`port full virtualization (also hardware-assisted virtualization in the following),
`as it offers relevant performance and isolation benefits. In fact, hardware virtu-
`alization allows the CPU to detect and possibly block unauthorized or malicious
`access to virtual resources. Nevertheless, no virtualization framework is immune
`to bugs. The virtualization platform can be an additional attack surface.
`
`2.2 CPU Virtualization
`
`The introduction of virtualization-enabling extensions in Intel and AMD CPUs
`dates back to 2005 [1,25]. VT-x and AMD-V were developed to add an additional
`more privileged execution ring where an hypervisor or virtual machine manager
`(VMM) could supervise actual access to physical resources from less privileged
`execution rings, as depicted in Fig. 2.
`CPUs are required to support some advanced extensions in order to allow
`the hypervisor to leverage them, as can be seen in Table 1. More in detail:
`
`— Intel VT-x AMD-V: These two CPU capability sets are the basic ingredi-
`ent of hardware-supported virtualization. They introduce Ring -1 allowing a
`guest virtual machine to run its kernel at standard privilege level (i.e., Ring
`0);
`
`168
`
`R. Di Pietro and F. Lombardi
`
`
`
`(oe Bl
`
`Content
`
`Collaboration
`
`Communication
`
`AN
`
`Runtime
`
`Object
`Storage
`
`和 一
`
`
`L_
`Database
`
`/
`™~
`
`
`
`Guest OS
`
`Guest Kernel
`
`本
`一
`
`
`
`
`
`Hypervisor
`
`a
`
`AAA
`
`
`
` ( HW (CPU/GPU/Disk/Net) }
`
`
`
`Fig. 1. Cloud layers and virtualization
`
`2.1
`
`Virtualization Frameworks
`
`The essential characteristics of the most widespread virtualization environments
`are summarized in Table 1.
`It
`is worth noting that all present hypervisors sup-
`port full virtualization (also hardware-assisted virtualization in the following),
`as it offers relevant performance and isolation benefits. In fact, hardware virtu-
`alization allows the CPU to detect and possibly block unauthorized or malicious
`access to virtual resources. Nevertheless, no virtualization framework is immune
`to bugs. The virtualization platform can be an additional attack surface.
`
`2.2
`
`CPU Virtualization
`
`The introduction of virtualization-enabling extensions in Intel and AMD CPUs
`dates back to 2005 [1,25]. VT-x and AMD-V were developed to add an additional
`more privileged execution ring where an hypervisor or virtual machine manager
`(VMM) could supervise actual access to physical resources from less privileged
`execution rings, as depicted in Fig. 2.
`CPUs are required to support some advanced extensions in order to allow
`the hypervisor to leverage them, as can be seen in Table 1. More in detail:
`
`- Intel VT-x AMD-V: These two CPU capability sets are the basic ingredi-
`ent of hardware-supported virtualization. They introduce Ring —1 allowing a
`guest virtual machine to run its kernel at standard privilege level (i.e., Ring
`0);
`
`

`

`Virtualization Technologies and Cloud Security
`
`169
`
`Table 1. CPU-related virtualization features
`
`X86-64 hypervisor Open source Hypervisor type Supported extension(s)
`
`Xen
`
`KVM
`
`VMWare ESX
`
`Hyper-V
`
`VirtualBox
`
`Y
`
`Y
`
`N
`
`N
`
`Y
`
`Native
`
`Hosted
`
`Native
`
`Native
`
`Hosted
`
`VT-x, AIVID-V, EPT, RVI, VT-d, AMID-Vi
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`VT-x, AIVID-V, EPT, RVI, VT-d, AMID-Vi
`
`VT-x, AIVID-V, EPT, RVI, VT-d, AMID-Vi
`
`VT-x, AIVID-V
`
`- Intel EPT, AMD RVI: Rapid Virtualization Indexing and Extended Page
`Tables, i.e. the Support for Second Level Address Translation (SLAT) that
`can significantly improve performance;
`— Intel VT-d, AMD-Vi: These CPU capabilities (directed I/O) allow faster
`I/O resource virtualization.
`
`Ring 3
`
`Ring 2
`
`Ring 1
`
`Rin
`
`Ring -1
`Hypery
`
`Guest erne)
`
`Device drivers
`
`Device drivers
`
`Applications
`
`Least privileged
`
`Most privileged
`
`Fig. 2. Execution rings for the x86_64 architecture. See also [19]
`
`2.3 GPU Virtualization
`
`The virtualization paradigm also applies to Graphics Processing Units (GPUs).
`Virtual machines can be given mediated or full access to GPU computing and
`memory resources. This allows offering a GPU-based Cloud similar to what is
`in place already for CPU-based computing resource sharing. Hypervisor support
`for GPU virtualization features (see Table 2) is still somehow limited as relevant
`GPU technology is still reserved for high-end GPUs. In fact, GPU virtualization
`is usually implemented following one of these main approaches [24]:
`
`— time-sharing: a single VM at a time is given direct access to the GPU.
`Time-slots are handled by the hypervisor;
`
`Virtualization Technologies and Cloud Security
`
`169
`
`Table 1. CPU-related virtualization features
`
`
`
`X86_64 hypervisor | Open source | Hypervisor type | Supported extension(s)
`
`
`
`Xen
`
`Y
`
`Native
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`KVM
`
`Y
`
`Hosted
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`VMWare ESX
`
`N
`
`Native
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`Hyper-V
`
`N
`
`Native
`
`VT-x, AMD-V, EPT, RVI, VT-d, AMD-Vi
`
`
`
`
`
`
`
`
`
`VirtualBox
`
`Y
`
`Hosted
`
`VT-x, AMD-V
`
`- Intel EPT, AMD RVI: Rapid Virtualization Indexing and Extended Page
`Tables, i.e. the Support for Second Level Address Translation (SLAT) that
`can significantly improve performance;
`~ Intel VT-d, AMD-Vi: These CPU capabilities (directed I/O) allow faster
`I/O resource virtualization.
`
`Lea st privileged
`
`
`
`
`
`
`
`
`
`
`Most privileged
`
`Gu
`
`
`
`
`
`Device drivers
`
`Device drivers
`
`Applications
`
`Fig. 2. Execution rings for the x86_64 architecture. See also [19]
`
`2.3.
`
`GPU Virtualization
`
`The virtualization paradigm also applies to Graphics Processing Units (GPUs).
`Virtual machines can be given mediated or full access to GPU computing and
`memory resources. This allows offering a GPU-based Cloud similar to what is
`in place already for CPU-based computing resource sharing. Hypervisor support
`for GPU virtualization features (see Table 2) is still somehow limited as relevant
`GPU technology is still reserved for high-end GPUs. In fact, GPU virtualization
`is usually implemented following one of these main approaches [24]:
`
`a time is given direct access to the GPU.
`一 time-sharing: a single VM at
`Time-slots are handled by the hypervisor;
`
`

`

`170
`
`R. Di Pietro and F. Lombardi
`
`— passthrough: the GPU is directly and permanently connected to a single
`VM that has direct access to it;
`— partitioned: the GPU resources are split into smaller virtual GPUs, assigned
`to single VMs.
`
`Once VMs have access to the GPU, the interaction between the guest and
`the real resource can be achieved in two different ways: backend virtualization
`or frontend virtualization [17]. Backend virtualization gives a direct connection
`between the VM and the GPU hardware. Frontend virtualization poses an inter-
`mediate layer between the guest and the hardware that has to leverage some kind
`of intermediate APIs to access the GPU. Some frontend virtualization examples
`are gVirt [56], vCUDA [53], GViM [22] and VOCL [59].
`
`Table 2. GPU-related virtualization features
`
`X86_64 hypervisor Open source Supported GPU virtualization technologies
`Xen
`Y
`Intel GVT-g, AMD MxGPU
`KVM
`Y
`Intel GVT-g, AMD MxGPU
`VMWare ESX
`N
`Intel GVT-g, AMD MxGPU
`Hyper-V
`N
`-
`Virtualbox
`Y
`-
`
`Particularly relevant here is AMD MxGPU technology [58], a partitioning
`strategy allowing users to have an equal share of the GPU. This hardware-
`based virtualization solution helps guaranteeing some isolation among different
`workloads and users.
`Intel GVT-g [56] is a full GPU virtualization solution with mediated
`passthrough (VFIO2 mediated device framework based). A virtual GPU instance
`is maintained for each VM, with part of performance critical resources directly
`assigned. The capability of running native graphics driver inside a VM, without
`hypervisor intervention in performance critical paths, achieves a good balance
`among performance, feature, and sharing capability.
`As GPUs are mainly used for computation tasks, security concerns about
`GPU virtualization are mainly focused on data leakage [16]. This can occur
`either by directly access data owned by the victim and stored within the GPU
`memory or by exploiting side channels. In [41], Christin et al. have depicted two
`adversary models:
`
`— serial adversary: this attacker has access to the same GPU or to the same
`GPU memory of the victim, before or after the victim. Hence, it can seek for
`traces previously left by the victim in different GPU memories;
`— parallel adversary: this attacker has access to the same GPU or GPU
`memory of the victim but in the same moment.
`
`2 Virtual Function I/O.
`
`170
`
`R. Di Pietro and F. Lombardi
`
`一 passthrough: the GPU is directly and permanently connected to a single
`VM that has direct access to it;
`一 partitioned: the GPU resources are split into smaller virtual GPUs, assigned
`to single VMs.
`
`Once VMs have access to the GPU, the interaction between the guest and
`the real resource can be achieved in two different ways: backend virtualization
`or frontend virtualization [17]. Backend virtualization gives a direct connection
`between the VM and the GPU hardware. Frontend virtualization poses an inter-
`mediate layer between the guest and the hardware that has to leverage some kind
`of intermediate APIs to access the GPU. Some frontend virtualization examples
`are gVirt [56], vCUDA [53], GViM [22] and VOCL [59].
`
`Table 2. GPU-related virtualization features
`
`
`
`X86_64 hypervisor | Open source | Supported GPU virtualization technologies
`
`
`
`Xen
`
`Y
`
`Intel GVT-g, AMD MxGPU
`
`
`
`KVM
`
`Y
`
`Intel GVT-g, AMD MxGPU
`
`
`
`VMWare ESX
`
`Hyper-V
`
`N
`
`N
`
`Virtualbox
`
`Y
`
`
`
`Intel GVT-g, AMD MxGPU
`
`-
`
`-
`
`
`
`
`
`
`
`
`
`Particularly relevant here is AMD MxGPU technology [58], a partitioning
`strategy allowing users to have an equal share of the GPU. This hardware-
`based virtualization solution helps guaranteeing some isolation among different
`workloads and users.
`full GPU virtualization solution with mediated
`a
`is
`Intel GVT-g [56]
`passthrough (VFIO? mediated device framework based). A virtual GPU instance
`is maintained for each VM, with part of performance critical resources directly
`assigned. The capability of running native graphics driver inside a VM, without
`hypervisor intervention in performance critical paths, achieves a good balance
`among performance, feature, and sharing capability.
`As GPUs are mainly used for computation tasks, security concerns about
`GPU virtualization are mainly focused on data leakage [16]. This can occur
`either by directly access data owned by the victim and stored within the GPU
`memory or by exploiting side channels. In [41], Christin et al. have depicted two
`adversary models:
`
`一 serial adversary: this attacker has access to the same GPU or to the same
`GPU memory of the victim, before or after the victim. Hence, it can seek for
`traces previously left by the victim in different GPU memories;
`一 parallel adversary: this attacker has access to the same GPU or GPU
`memory of the victim but in the same moment.
`
`? Virtual Function I/O.
`
`

`

`Virtualization Technologies and Cloud Security
`
`171
`
`3 Virtualization Security Issues
`
`Virtualization technologies underlying Cloud computing infrastructure them-
`selves constitute vulnerable surface. In a Cloud scenario, we can observe the
`following major security challenges [35]:
`
`— privileged user access: access to sensitive data in the Cloud has to be
`restricted to a subset of trusted users (to mitigate the risk of abuse of high
`privilege roles);
`— lack of data/computation isolation: one instance of customer data has
`to be fully isolated from data belonging to other customers;
`— reliability/availability: the Cloud provider has to setup an effective repli-
`cation and recovery mechanism to restore services, should a security issue
`occur;
`
`Virtualization potentially widens Cloud computing attack vectors such as:
`
`hypervisor: the hypervisor is the software element sitting in between the host
`and guests to allow mediated access to physical resources. This layer should be
`transparent to a non-privileged user running into the guest. Unfortunately,
`its presence cannot be fully hidden [46]. As such, an attacker can exploit
`hypervisor vulnerabilities to gain access to both the host system and other
`guests. Hypervisors also provide emulation capabilities for missing hardware
`elements. However, this is a potential attack surface, as demonstrated by Ray
`[47] and Geffner [26];
`pivoting: users can often login into specific services hosted by a VM. Once
`inside, the attacker could also exit the virtual machine she accessed, to dam-
`age the underlying physical system and/or sibling VMs.
`— migration: virtual machines can be moved over different hosts for load bal-
`ancing or disaster recovery. This "migration" is performed by copying the
`VM image over the network. An attacker can potentially eavesdrop data and
`perform a man in the middle attack if the channel is not encrypted.
`— resource allocation: virtual machines are usually executed on-demand at
`run-time, thus making the resource allocation and management process as
`dynamic as possible. Resource sharing can thwart the security of the host sys-
`tem as well as of its virtual machines. In fact, negligence in cleaning resources
`before releasing them to others can lead to severe data leakage. As an exam-
`ple, data written by a VM into volatile or persistent storage can be accessed
`by others who have access to the same elements [50];
`
`The above attacks show how virtual machines and the physical machines
`hosting them can be thwart by attackers targeting the host or just the virtual
`machine. Some mitigating approaches can be as follows:
`
`— host side: vulnerabilities in the implementation of the hypervisor can some-
`what be mitigated by frequently updating the hypervisor to reduce 0-days
`vulnerability window;
`
`Virtualization Technologies and Cloud Security
`
`171
`
`3
`
`Virtualization Security Issues
`
`Virtualization technologies underlying Cloud computing infrastructure them-
`selves constitute vulnerable surface. In a Cloud scenario, we can observe the
`following major security challenges [35]:
`
`一 privileged user access: access to sensitive data in the Cloud has to be
`restricted to a subset of trusted users (to mitigate the risk of abuse of high
`privilege roles);
`- lack of data/computation isolation: one instance of customer data has
`to be fully isolated from data belonging to other customers;
`- reliability /availability: the Cloud provider has to setup an effective repli-
`cation and recovery mechanism to restore services, should a security issue
`occur;
`
`Virtualization potentially widens Cloud computing attack vectors such as:
`
`一 hypervisor: the hypervisor is the software element sitting in between the host
`and guests to allow mediated access to physical resources. This layer should be
`transparent to a non-privileged user running into the guest. Unfortunately,
`its presence cannot be fully hidden [46]. As such, an attacker can exploit
`hypervisor vulnerabilities to gain access to both the host system and other
`guests. Hypervisors also provide emulation capabilities for missing hardware
`elements. However, this is a potential attack surface, as demonstrated by Ray
`[47] and Geffner [26];
`一 pivoting: users can often login into specific services hosted by a VM. Once
`inside, the attacker could also exit the virtual machine she accessed, to dam-
`age the underlying physical system and/or sibling VMs.
`— migration: virtual machines can be moved over different hosts for load bal-
`ancing or disaster recovery. This “migration” is performed by copying the
`VM image over the network. An attacker can potentially eavesdrop data and
`perform a man in the middle attack if the channel is not encrypted.
`— resource allocation: virtual machines are usually executed on-demand at
`run-time, thus making the resource allocation and management process as
`dynamic as possible. Resource sharing can thwart the security of the host sys-
`tem as well as of its virtual machines. In fact, negligence in cleaning resources
`before releasing them to others can lead to severe data leakage. As an exam-
`ple, data written by a VM into volatile or persistent storage can be accessed
`by others who have access to the same elements [50];
`
`The above attacks show how virtual machines and the physical machines
`hosting them can be thwart by attackers targeting the host or just the virtual
`machine. Some mitigating approaches can be as follows:
`
`— host side: vulnerabilities in the implementation of the hypervisor can some-
`what be mitigated by frequently updating the hypervisor to reduce 0-days
`vulnerability window;
`
`

`

`172
`
`R. Di Pietro and F. Lombardi
`
`— network monitoring: monitoring and analyzing internal communications
`between sibling guests can help; nevertheless, malicious network behavior is
`dif₹icult to detect by means of traditional intrusion detection systems and
`intrusion prevention systems;
`— encryption: to mitigate such migration attacks encryption of the data in
`transit can be used; nevertheless, this proves quite demanding on perfor-
`mance, and consequently on costs.
`— on allocation: this attack can be dealt with by carefully deleting/cleaning
`resources either persistent or volatile that have been previously assigned to
`other VMs;
`
`3.1 Co-location Issues
`
`Co-location of virtual machines by different tenants on the same physical host is
`particularly frequent in Cloud computing. Virtual resources assigned to a tenant
`might get hacked by other virtual resources assigned to different tenants that are
`co-located within the same physical machine. Co-location can lead to different
`issues as follows:
`
`— information leakage: by reusing the same physical hardware to allocate
`virtual resources, tenants might be able to exploit forensic tools to recover
`sensitive data from previous tenants;
`performance degradation: malicious tenants co-located in the same physi-
`cal host might be able to make an uneven/widely varying use of computational
`power with high cpu-intensive co-located virtual machines with the final goal
`of degrading victim's performances;
`— service disruption: malicious tenants sharing physical resources with their
`victim might be able to lead the hardware to unexpected behaviors thus
`causing a service disruption against the victim.
`
`A large number of research results have highlighted the actual existence of
`co-location vulnerabilities [48,61]. Such papers show that completely preventing
`tenants from sharing the same physical resources is practically unfeasible (due to
`rising costs). A viable solution [3] might be an attribute-based approach where
`tenants can express constraints over both virtual and physical resource alloca-
`tion. Tenants would be able to indicate an high data sensitivity, thus requesting
`to avoid co-location. In this way, co-location will not be allowed for virtual
`resources working on high sensitive information thus lowering the chance of data
`leakage. As a consequence, virtual resource cost would be increased. This could
`be an acceptable trade-off in most sensitive scenarios.
`
`3.2 Randomness and Virtualization
`
`Cloud providers usually deploy identical VM clones when needed to satisfy
`request load. As such, it often happen that the very same images are used for
`different tenants. As a consequence, the internal random pool for clone VMs is
`
`172
`
`R. Di Pietro and F. Lombardi
`
`一 network monitoring: monitoring and analyzing internal communications
`between sibling guests can help; nevertheless, malicious network behavior is
`difficult to detect by means of traditional intrusion detection systems and
`intrusion prevention systems;
`一 encryption: to mitigate such migration attacks encryption of the data in
`transit can be used; nevertheless, this proves quite demanding on perfor-
`mance, and consequently on costs.
`— on allocation: this attack can be dealt with by carefully deleting/cleaning
`resources either persistent or volatile that have been previously assigned to
`other VMs;
`
`3.1
`
`Co-location Issues
`
`Co-location of virtual machines by different tenants on the same physical host is
`particularly frequent in Cloud computing. Virtual resources assigned to a tenant
`might get hacked by other virtual resources assigned to different tenants that are
`co-located within the same physical machine. Co-location can lead to different
`issues as follows:
`
`一 information leakage: by reusing the same physical hardware to allocate
`virtual resources, tenants might be abl