Characterizing Vulnerabilities in Platform Security: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
This article provides some information on works related to characterizing Vulnerabilities within the Xen Project Hypervisor, as well as related projects.


== Types of Vulnerabilities handled by the Xen Project Security Team ==
=== 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:
* '''Xen hypervisor''' (see [https://xenbits.xen.org/docs/unstable/support-matrix.html support-matrix] for details)
* '''Hypervisor toolstack(s)''' - e.g. [http://xenbits.xen.org/xsa/advisory-271.html XSA 271], [http://xenbits.xen.org/xsa/advisory-266.html XSA 266]
* '''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]
* '''Some QEMU components''' (see [https://xenbits.xen.org/docs/unstable/support-matrix.html support-matrix] for details)


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.
== Prior Work in this area ==

=== Severity ===
Unlike other open source project, 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. [http://xenbits.xen.org/xsa/advisory-273.html XSA 273])
* When '''related attack vectors''' can be addressed by the same mitigation (e.g. [http://xenbits.xen.org/xsa/advisory-201.html XSA 201], [http://xenbits.xen.org/xsa/advisory-218.html XSA 218], [http://xenbits.xen.org/xsa/advisory-196.html XSA 196])

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 [https://www.cvedetails.com CVE Details] will consume vulnerability data published by the Xen Project and publish it under a Xen-specific vendor ID (e.g. [https://www.cvedetails.com/vulnerability-list/vendor_id-6276/XEN.html 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 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 [https://wiki.qemu.org/SecurityProcess QEMU Security Process]).

== Prior Work Characterizing Vulnerabilities ==
* 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]
* 2016: Haibo Chen: [http://alchem.usc.edu/ceng-seminar/slides/2016/haibo_chen.pdf Virtualization Security: The Good, The Bad and The Ugly (slides)]
* 2016: Haibo Chen: [http://alchem.usc.edu/ceng-seminar/slides/2016/haibo_chen.pdf Virtualization Security: The Good, The Bad and The Ugly (slides)]

Revision as of 20:11, 10 October 2018

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

Types of Vulnerabilities handled by the Xen Project Security Team

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:

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.

Severity

Unlike other open source project, 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)

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 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).

Prior Work Characterizing Vulnerabilities

Retrieved from "https://wiki.xenproject.org/index.php?title=Characterizing_Vulnerabilities_in_Platform_Security&oldid=19017"