[Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

[George Dunlap <george.dunlap@xxxxxxxxxx>]

The Xen Security Team has dealt with a number of issues recently where
it wasn't exactly clear whether we should issue an advisory or not:
the Xen Security Response Process only mentiones "'vulnerabilities",
without specifying what constitutes a vulnerability.

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 every advisory
has the risk that it will be picked up and blown out of proportion by
the media.  So we want to make sure to only issue advisories for
issues that are worth the cost.

We would like guidelines from the community about what sorts of issues
should be considered security issues (and thus will have advisories
issued).  Below is a draft of a section I* am proposing to be added to
the Xen Security Policy, just under the section "Specific Process".

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 will not be
considered a security issue unless it may contain sensitive guest or
user data), and 4 (if no known operating systems are vulnerable to a
bug, no advisory will be issued).

Please give feedback.  Thanks!

* This has my own proposal; it is inspired by discussions the security
team has had, but it has not been vetted by them.

====

# 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 vulnerable".

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, a bug will only be considered a vulnerability
if there are known operating systems on which the attack can be
executed.  If no operating system can be found which allows such an
attack, no advisory will be issued.

If a bug requires a vulnerable operating system to be exploitable, 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 may also test or otherwise investigate
the vulnerability of some proprietary operating systems.

(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