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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 17/02/17 10:11, Lars Kurth wrote:
> 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.

Yes, running our own survey might be a sensible way to get people to
interact who seem resistant to giving an opinion on the mailing list.
> 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. 

Right -- I think all of the developers take it as a given that we intend
to fix all bugs that we're aware of.  It's slightly annoying to have to
spell this out (when this section is already very verbose), but I
suppose given people's responses we'll have to do that.

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

Right, on the one hand flagging these up might make sense.  But it opens
up some questions: Do we do embargoes for this sort of thing?  Do we
backport the patches to security trees?

If not, then it probably won't significantly reduce the work for the
security team.  Will it reduce the work for our users?  If most people
ignore XSNs ("Xen Security Notes"), then it will; if most people feel
obligated to apply them anyway, then perhaps it won't.  Will it have any
effect from a PR perspective?

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

I think Jan said this, but there is no security issue here.  A guest
kernel could just decide to while(1) or cause itself a triple-fault, and
that would be the same as a guest kernel being able to crash itself.

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

As Jan said, at the moment we already don't cover highly disaggregated
environments, because nobody seemed to be using them.  If someone wants
such an environment to be covered, we hope the invitation at the top of
the section will encourage people to ask.  (Although our experience
getting comments on this proposal is not very encouraging.)

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

Yes, the idea is that the leak itself doesn't contain anything valuable;
in order to be useful it is still required to have yet another
vulnerability; and any such vulnerability would itself have an XSA
issued when it was discovered.

On the other hand, pro-actively fixing such a leak would mean that if
the "bad guys" did have a zero-day, it might be less useful.

On this particular question the security team weren't in complete
agreement, and we hoped to have feedback from the community (which is
why I specifically mentioned it in my intro).

 -George

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