Issuing advisories has a cost: It costs the security team significant amounts of time to craft and send the advisories; it costs many of our downstreams time to apply, build, and test patches; and it costs many of our users time to decide whether to do an update, and if so, to test and deploy it.
Given this, the Xen Project Security Team wants to clarify when they should issue an advisory or not: the Xen Security Response Process only mentions “‘vulnerabilities”, without specifying what constitutes a vulnerability.
We would like guidelines from the community about what sorts of issues should be considered security issues (and thus will have advisories issued). I have posted the second version a draft of a section I am proposing to be added to the Xen Security Policy to xen-devel; a copy is included below for your convenience. There are only minor modifications from the first draft, so barring major feedback from the wider community it will likely achieve consensus. If you want input, now is the time to speak up.
Most of it is just encoding long-established practice. But there are two key changes and / or clarifications that deserve attention and discussion:
- Criteria 2c: Leaking of mundane information from Xen or dom0 will not be considered a security issue unless it may contain sensitive guest or user data
Criteria 4: If no operating systems are vulnerable to a bug, no advisory will be issued.
If you want to weigh in on the question, please join the discussion on xen-devel before 28 February. The title of the thread is “RFC v2: Scope of Vulnerabilities for which XSAs are issued”.
Scope of vulnerabilities covered by this process
All security issues are bugs, but not all bugs are security issues. This section is meant to be a guide from the Xen community to the Xen security response team regarding which bugs should have advisories issued for them. Discoverers are encouraged to err on the side of caution and report any potential vulnerabilities to the security team. These guidelines are not meant to be set in stone; if they do not fit your needs as a user, please raise the issue on xen-devel.
Every potential vulnerability will have a source context, an effect, and a target effect context. For instance, a bug may allow a guest user (source context) to escalate their privileges (effect) to that of the guest kernel (target context); or it may allow a guest administrator (source context) to severely degrade the disk performance (effect) of another guest (target context).
Only the following source/target context pairs will be considered vulnerabilities:
1a. The source is the guest userspace, guest kernel, or QEMU stubdomain, and the target is the hypervisor, dom0 and toolstack.
1b. The source is the guest userspace, guest kernel, or QEMU stubdomain, and the target is another guest.
1c. The source is guest userspace, and the target is the guest kernel, or other guest userspace processes.
This means, for instance, that bug which allows a guest kernel to perform a DoS on itself will not be considered a security vulnerability. It also means, at the moment, that the security team will not issue advisories for highly disaggregated environments.
Only some effects are considered vulnerabilities; and whether they are vulnerabilities depends on the target context:
2a. Privilege escalation: causing arbitrary code to be run in the target context. This will be considered a vulnerability in all cases above (1a-c).
2b. Denial of service: Causing termination of or significant degradation of performance in the target context. This will be considered a vulnerability in all cases above (1a-c).
2c. Information leakage: The attacker in the source context is able to obtain information from the target context. This will be considered a vulnerability in all cases in 1b and 1c. It will only be considered a vulnerability in the case of 1a if information obtained is considered sensitive in and of itself: for example, host administrator passwords or information about other users on the host.
In particular, information leakage from Xen, domain 0, or the toolstack to an unprivileged guest will not be considered a vulnerability unless there is a chance that that information may contain information from a guest, or other sensitive information from domain 0. For instance, copying uninitialized data from Xen’s stack will generally be considered a vulnerability, because it may contain stale guest data. But if it can be shown that the data copied will always be Xen-internal information (for instance, pointers or other internal structures), then an advisory will not be issued. This is the case even if that information could be useful in making another
exploit more effective (for instance, if it exposed virtual addresses of sensitive data structures).
3. The security team will only issue advisories for certain configurations. Bugs in Xen features listed as “experimental” or “tech preview” will not have advisories issued for them. Bugs in QEMU will only have advisories issued when configured as described in docs/misc/qemu-xen-security.
4. The security team will only issue an advisory if there is a known combination of software in which the vulnerability can be exploited.
In most cases, the software which contains the bug is also the target of the attack: that is, a bug in Xen allows an unprivileged user to crash Xen, a bug in QEMU allows an unprivileged user to escalate its privileges to that of the QEMU process. In these cases “using Xen” or “using QEMU” imples “being vunlerable”. But this is not always so: for instance, a bug in the Xen instruction emulator might allow a guest user to attack the guest kernel, if the guest kernel behaves in a certain way, but not if it behaves in other ways.
In such a case, the Xen Security Team will pro-actively investigate the vulnerability of the following open-source operating systems: Linux, OpenBSD, FreeBSD, and NetBSD. The security team will also make an effort to investigate the vulnerability of Microsoft Windows. If we are reasonably certain that none of these operating systems are vulnerable, and there are no other operating systems known to be vulnerable, then no advisory will be issued.
(An example of this scenario is XSA-176: There was a bug in the handling of the pagetable PS bits for L3 and L4; but no known operating systems were vulnerable to an exploit as a result of the bug. Under these guidelines, XSA-176 would not have been issued.)