Difference between revisions of "Characterizing Vulnerabilities in Platform Security"

From Xen
(Vulnerability Scope Boundaries)
(Added block on mitigations, relevance to reduction in scope/impact and reference link to Threat Modeling book)
 
(One intermediate revision by one other user not shown)
Line 2: Line 2:
   
 
== Vulnerabilities handled by the Xen Project Security Team ==
 
== Vulnerabilities handled by the Xen Project Security Team ==
  +
System architecture, software configuration, the deployment use case and associated threat model, each have significant impact on the level of exposure to vulnerability defects.
  +
 
=== Vulnerability Scope Boundaries ===
 
=== Vulnerability Scope Boundaries ===
 
The Xen Project Security Response team follows the project's [https://xenproject.org/security-policy.html Security Response Process] and publishes security issue via [http://xenbits.xen.org/xsa/ xenbits.xen.org/xsa]. Security issues covered by the process include issues within the following vulnerability scope boundaries which are restricted by the [https://xenbits.xen.org/docs/unstable/support-matrix.html Xen Project Support Matrix]:
 
The Xen Project Security Response team follows the project's [https://xenproject.org/security-policy.html Security Response Process] and publishes security issue via [http://xenbits.xen.org/xsa/ xenbits.xen.org/xsa]. Security issues covered by the process include issues within the following vulnerability scope boundaries which are restricted by the [https://xenbits.xen.org/docs/unstable/support-matrix.html Xen Project Support Matrix]:
Line 8: Line 10:
 
* '''Linux kernel components affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-274.html XSA 274], [http://xenbits.xen.org/xsa/advisory-270.html XSA 270]
 
* '''Linux kernel components affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-274.html XSA 274], [http://xenbits.xen.org/xsa/advisory-270.html XSA 270]
 
* '''Hardware vulnerabilities affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-273.html XSA 273], [http://xenbits.xen.org/xsa/advisory-265.html XSA 265], [http://xenbits.xen.org/xsa/advisory-254.html XSA 254]
 
* '''Hardware vulnerabilities affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-273.html XSA 273], [http://xenbits.xen.org/xsa/advisory-265.html XSA 265], [http://xenbits.xen.org/xsa/advisory-254.html XSA 254]
* '''Some QEMU components''' - e.g. [http://xenbits.xen.org/xsa/advisory-262.html XSA 262],
+
* '''Some QEMU components''' - e.g. [http://xenbits.xen.org/xsa/advisory-262.html XSA 262], [http://xenbits.xen.org/xsa/advisory-211.html XSA 211]
* '''Bootloaders and other tools affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-198.html XSA 198], [http://xenbits.xen.org/xsa/advisory-211.html XSA 211]
+
* '''Bootloaders and other tools affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-198.html XSA 198]
 
* '''Warnings about the security status of functionality, security impact of some hardware, or similar ''' - e.g. [http://xenbits.xen.org/xsa/advisory-124.html XSA-124], [http://xenbits.xen.org/xsa/advisory-163.html XSA 163][http://xenbits.xen.org/xsa/advisory-99.html XSA 99] - in such cases no CVE is issued
 
* '''Warnings about the security status of functionality, security impact of some hardware, or similar ''' - e.g. [http://xenbits.xen.org/xsa/advisory-124.html XSA-124], [http://xenbits.xen.org/xsa/advisory-163.html XSA 163][http://xenbits.xen.org/xsa/advisory-99.html XSA 99] - in such cases no CVE is issued
   
  +
Defect advisories include statements that indicate which components and which subset of systems are affected.
In addition, some vulnerabilities will impact only a subset of Xen versions, a specific architecture (x86 Intel, x86 AMD, Arm 32, Arm 64) or specific configuration and/or virtualization mode (PV, HVM, PVH). Typically products based on Xen will be based on a specific version, subset of features and specific architecture. For example, many Xen based products and services will only support a subset of virtualization modes.
 
  +
  +
It is common for defects to affect only a single platform architecture, (ie. only one of: x86 Intel, x86 AMD, ARM 32-bit, ARM 64-bit), and/or only a single VM virtualization mode (ie. PV, HVM or PVH), and to have '''mitigations already available and present in deployed systems''', via methods including:
  +
* '''System disaggregation''', platform configuration (driver domains, stubdomains, ...)
  +
* '''Software configuration''' (features enabled, XSM policy, boot options, KCONFIG, ...),
  +
* '''Enabling hardware-based security features''' (IOMMU, SMAP, SMEP, ...),
  +
* '''Platform VM configuration''' (device passthrough, device driver domains, ...)
  +
* '''Guest VM configuration''' (virtualization mode, Shim, virtual device configuration, ...)
  +
  +
The consequence is that XSA/CVE defects are typically relevant only to a subset of systems.
  +
  +
Products based on Xen are each based on a specific software version, a subset of features and selected hardware architectures. For example, many Xen based products and services will only support a subset of virtualization modes.
   
 
=== Severity ===
 
=== Severity ===
Line 46: Line 59:
 
* 2012: Nelson Gonzalez, Charles Miers, Fernando Redígolo, Marcos Simplício, Tereza Carvalho, Mats Näslund, Makan Pourzandi - University of São Paulo, Ericsson Research, State University of Santa Catarina, Brazil: [https://link.springer.com/content/pdf/10.1186%2F2192-113X-1-11.pdf A quantitative analysis of current security concerns and solutions for cloud computing]
 
* 2012: Nelson Gonzalez, Charles Miers, Fernando Redígolo, Marcos Simplício, Tereza Carvalho, Mats Näslund, Makan Pourzandi - University of São Paulo, Ericsson Research, State University of Santa Catarina, Brazil: [https://link.springer.com/content/pdf/10.1186%2F2192-113X-1-11.pdf A quantitative analysis of current security concerns and solutions for cloud computing]
 
* 2013: Diego Perez-Botero, Jakub Szefer and Ruby B Lee - Princeton University, Princeton, NJ, USA: [http://palms.ee.princeton.edu/system/files/scc2013.pdf Characterizing Hypervisor Vulnerabilities in Cloud Computing Servers]
 
* 2013: Diego Perez-Botero, Jakub Szefer and Ruby B Lee - Princeton University, Princeton, NJ, USA: [http://palms.ee.princeton.edu/system/files/scc2013.pdf Characterizing Hypervisor Vulnerabilities in Cloud Computing Servers]
  +
* 2014: Adam Shostack - Microsoft, Trustworthy Computing Team: [https://www.wiley.com/en-us/Threat+Modeling%3A+Designing+for+Security-p-9781118809990 Threat Modeling: Designing for Security] ISBN: 978-1-118-80999-0
 
* 2016: Haibo Chen - Shanghai Jiao Tong University, China: [http://alchem.usc.edu/ceng-seminar/slides/2016/haibo_chen.pdf Virtualization Security: The Good, The Bad and The Ugly (slides)]
 
* 2016: Haibo Chen - Shanghai Jiao Tong University, China: [http://alchem.usc.edu/ceng-seminar/slides/2016/haibo_chen.pdf Virtualization Security: The Good, The Bad and The Ugly (slides)]
 
* 2016: Ammarit Thongthua, Sudsanguan Ngamsuriyaroj - Mahidol University, Thailand: [https://ieeexplore.ieee.org/abstract/document/7600180 Assessment of Hypervisor Vulnerabilities]
 
* 2016: Ammarit Thongthua, Sudsanguan Ngamsuriyaroj - Mahidol University, Thailand: [https://ieeexplore.ieee.org/abstract/document/7600180 Assessment of Hypervisor Vulnerabilities]

Latest revision as of 19:13, 11 October 2018

This article provides some information on works related to characterizing Vulnerabilities within the Xen Project Hypervisor, as well as related projects.

Vulnerabilities handled by the Xen Project Security Team

System architecture, software configuration, the deployment use case and associated threat model, each have significant impact on the level of exposure to vulnerability defects.

Vulnerability Scope Boundaries

The Xen Project Security Response team follows the project's Security Response Process and publishes security issue via xenbits.xen.org/xsa. Security issues covered by the process include issues within the following vulnerability scope boundaries which are restricted by the Xen Project Support Matrix:

  • Xen hypervisor
  • Hypervisor toolstack(s) - e.g. XSA 271, XSA 266
  • Linux kernel components affecting Xen - e.g. XSA 274, XSA 270
  • Hardware vulnerabilities affecting Xen - e.g. XSA 273, XSA 265, XSA 254
  • Some QEMU components - e.g. XSA 262, XSA 211
  • Bootloaders and other tools affecting Xen - e.g. XSA 198
  • Warnings about the security status of functionality, security impact of some hardware, or similar - e.g. XSA-124, XSA 163XSA 99 - in such cases no CVE is issued

Defect advisories include statements that indicate which components and which subset of systems are affected.

It is common for defects to affect only a single platform architecture, (ie. only one of: x86 Intel, x86 AMD, ARM 32-bit, ARM 64-bit), and/or only a single VM virtualization mode (ie. PV, HVM or PVH), and to have mitigations already available and present in deployed systems, via methods including:

  • System disaggregation, platform configuration (driver domains, stubdomains, ...)
  • Software configuration (features enabled, XSM policy, boot options, KCONFIG, ...),
  • Enabling hardware-based security features (IOMMU, SMAP, SMEP, ...),
  • Platform VM configuration (device passthrough, device driver domains, ...)
  • Guest VM configuration (virtualization mode, Shim, virtual device configuration, ...)

The consequence is that XSA/CVE defects are typically relevant only to a subset of systems.

Products based on Xen are each based on a specific software version, a subset of features and selected hardware architectures. For example, many Xen based products and services will only support a subset of virtualization modes.

Severity

Unlike other open source projects, the Xen Project always publishes XSAs for security bugs of low severity. The primary reason for this approach is that there are many different products for very different use-cases, ranging from server virtualisation/cloud computing, to desktop applications (such as Qubes OS), to embedded Xen distributions and that severity cannot usually be determined without considering the specific use-case and context.

CVE Numbers and CVE Publication Dates

Note that there is not always a 1-2-1 mapping between CVE numbers and XSAs. Sometimes multiple CVE numbers exist for a single XSA. This typically is the case in the following circumstances:

  • When multiple Hardware vulnerabilities affecting Xen can be addressed by the same mitigation (e.g. XSA 273)
  • When related attack vectors can be addressed by the same mitigation (e.g. XSA 201, XSA 218, XSA 196)

In addition, there are some XSAs, which do not have CVE numbers: this typically applies for

  • Unused/Withdrawn XSA numbers
  • Warnings about the security status of functionality - e.g. XSA 163
  • Warnings about the security impact of some hardware - e.g. XSA 124
  • Warnings about security issues in example code that may have been productised - e.g. XSA 99

Note that the mapping of CVE numbers to years may not match the XSA publication dates: this frequently happens towards the end of a calendar year.

CVE databases

CVE databases such as CVE Details will consume vulnerability data published by the Xen Project and publish it under a Xen-specific vendor ID (e.g. Xen vendor on CVE Details). This means that vulnerabilities with very different vulnerability scope boundaries (e.g. Xen Hypervisor, Hypervisor toolstack(s), Linux kernel components affecting Xen, Hardware vulnerabilities affecting Xen, QEMU components) will all be listed under the Xen-specific vendor ID. Manual filtering of vulnerabilities is required when considering a specific scope, use-case or architecture.

Upstreams

Security teams of Xen Upstreams (e.g. Linux Distros or QEMU) will notify the Xen Project Security Team of security issues they suspect will impact Xen. However, this usually depends on the wishes of the discoverer of an issue (for example, see QEMU Security Process).

Considerations when Characterizing Xen Vulnerabilities or comparing Hypervisors

When Characterizing Xen Vulnerabilities it is important to consider the following factors

  • Vulnerability Scope Boundaries
  • Use-case and Hypervisor Configurations, CPU Architecture and Virtualization modes that may be used

When comparing Hypervisors (or in general similar software), it is important to note that different Hypervisors have different architectures and different approaches to Software Vulnerability Management. For example, it is common practice amongst many open source software projects to not handle low-severity security issues. Also, for some technologies there is not always a single place from which to obtain a definite list of vulnerabilities affecting the technology.

Prior Work Characterizing Vulnerabilities