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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

George,

thanks for pulling this together.

> On 14 Feb 2017, at 17:25, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> 
> Here is version two, with minor revisions based on comments from version
> 1.  Please give any feedback by 28 February.  Thanks!

I think we may need to take a step back on this, given the coverage of the 
proposal in the media and the response this has caused there.

This puts us into a situation where
a) Lots of emotions and opinions were generated elsewhere to a set of questions 
that were not phrased well
b) People have voted on the proposal elsewhere, but we don't know whether they 
are Xen users or not
c) Thus, we don't know how valid the data generated elsewhere is

Assuming, that we don't get additional feedback on this thread and we moved 
ahead on the grounds that no feedback to this proposal was given, we could be 
accused of ignoring our user-base.

We may need to revisit some of the proposal and run our own survey. The survey 
should, like in the past, require an e-mail address and a tick-box whether the 
user is using or developing Xen. I will also ask the Advisory Board for input, 
as some of the responses to the Register article raised some interesting 
questions.

I would probably also want to look at 
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01500.html 
again. I think there is some merit in a predictable XSA publication schedule. 
But I will comment on that thread separately.

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

I think it is worthwhile looking at what other projects have done, that have a 
process similar to ours. For example OpenStack differentiates between OSSAs 
(similar to XSAs), see

https://security.openstack.org/vmt-process.html

and OSSNs, see 
https://wiki.openstack.org/wiki/Security/Security_Note_Process

with the following taxonomy

https://security.openstack.org/vmt-process.html#incident-report-taxonomy

They had a very similar process to ours and introduced the differentiation 
between OSSAs and OSSNs for similar reasons than we created this proposal.

Also, do we have a general sense of how many XSAs that we have handled in the 
past, would not have been handled had the proposal been in place? It seems to 
me that we are talking about a very small number. But that readers of the 
proposal think that we suddenly would only handle 50% of what we have handled 
in the past. 

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

I think the key problem with the proposal as it stands is that it does not 
explain what we do with reported issues that have been deemed to be outside the 
context of this process. From a process perspective, you would of course only 
change the process affected, but that is a bad communication tactic.

Some of the comments simply assume that we would not fix them. My understanding 
is that we would fix them, but not issue advisories. 

But would we highlight them as potential security issues in some other 
identifiable way? (in a similar way as OpenStack does with OSSNs)

Would we publish information on how many issues were reported and how many were 
not security issues at all, and how many didn't meet our criteria?

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

Maybe the better way to phrase this is: "will not be considered a Xen security 
vulnerability." (But presumably it is a vulnerability elsewhere, e.g. Linux, 
...)

Again in this case, we would not issue an XSA, but what would we do?

Direct the reporter to the appropriate project and/or raise the issue on 
another project. Clearly in that case, there is a security issue, but it's not 
Xen specific.
  
> 
> It also means, at the moment, that the security team
> will not issue advisories for highly disaggregated environments.

I am not sure I fully understand this, because 1b presumably covers 
disaggregated environments. Also, what would the practical implications be? In 
particular for downstream such as QubesOS, OpenXT and others ? Is there a 
single XSA which we have covered in the past, which we would not handle?

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

Looking at https://www.cvedetails.com/vendor/6276/XEN.html, we historically 
also had issues which were outside these categories. So maybe something is 
missing there.

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

What is the rationale for this? At least for the purpose of the discussion, 
that should be more clearly spelled out.
In some sense, we are saying that we are not covering this case, because 
although technical information is leaked, an attacker can't do anything with it 
and as such an XSA is not necessary. But that argument may need to be examined 
and tested.

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

Let me look at this at the top of the thread

Lars


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