[Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

[George Dunlap <george.dunlap@xxxxxxxxxx>]

Here is version two, with minor revisions based on comments from version
1.  Please give any feedback by 28 February.  Thanks!

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).  This is the second version; the first version was pretty well
received.  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.

---

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel