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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 4 Jan 2017, George Dunlap wrote:
> 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.

+1 on the whole doc, thanks George

I'd also like to point out that this wording also prevents theoretical
vulnerabilities, such as XSA-166, to turn into XSAs.


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

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