[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Tue, 24 Jan 2017 16:33:18 +0000
  • Accept-language: en-GB, en-US
  • Cc: Ian Jackson <Ian.Jackson@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Jan 2017 16:35:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHSZozNtW+9RbIwU0yW0iPSqqtJPaFGDiPJgAF/SoCAAALnAIAAN1aAgAABzQCAABfNgA==
  • Thread-topic: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

> On Jan 24, 2017, at 3:08 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>>>> On 24.01.17 at 16:01, <George.Dunlap@xxxxxxxxxx> wrote:
> 
>>> On Jan 24, 2017, at 11:43 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>>>>> On 24.01.17 at 12:33, <ian.jackson@xxxxxxxxxxxxx> wrote:
>>>> Jan Beulich writes ("Re: [Xen-devel] RFC: Adding a section to the Xen 
>> security 
>>>> policy about what constitutes a vulnerability"):
>>>>> "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 will also test or otherwise investigate
>>>>> the vulnerability of supported Windows versions, and it may also do so
>>>>> for some other proprietary operating systems."
>>>> 
>>>> I don't think we can promise to come up with a definitely conclusion
>>>> for any proprietary system, can we ?  Answering such a question for
>>>> Windows is not within our power because we don't have the source code.
>>> 
>>> Well - see George's original mail, which the above was a reply to.
>>> He has suggested that there's enough knowledge around.
>>> 
>>>> The question, which the above text leaves unclear, is, what do we do
>>>> if we aren't sure whether there are configurations of Windows which
>>>> have the exposed behaviour.
>>> 
>>> I think I had given my opinion on this in an earlier mail: If in doubt,
>>> we ought to issue an advisory.
>> 
>> And my response (in not so many words) was that the statement, “If in doubt 
>> we ought to issue an advisory” is too black-and-white, and (it seems to me) 
>> will probably always result in an advisory being issued; thus making the 
>> whole discussion moot.  
>> 
>> But perhaps we’re using the word “doubt” a bit differently.  In the case of 
>> XSA-176 and 192, for instance, would you have said that we had any doubts 
>> about whether Windows was vulnerable?
> 
> For 192 - no. For 176 I wouldn't be that sure.

I guess it’s not really a fair question, as we didn’t really spend a lot of 
time investigating Windows because we were going to issue the advisory anyway.

I think under the above rule, for XSA-176, I think we would either want to have 
an answer from someone in MS, or we’d instrument a version of Xen to look for 
the PSE bit in L3 and L4 pagetables and run it through our regression test.  If 
there was no evidence of any of our tested versions of Windows setting the L4 
PSE bit, or setting the L3 bit when 1G superpages were not advertized, I would 
be comfortable not issuing an advisory.  

On the other hand, if we really had no idea — we had no test to perform and we 
hadn’t been able to contact anyone from within MS, and it seemed like Windows 
might plausibly be vulnerable, then I would agree that issuing an advisory 
would make sense.

What do you think?

But I’m not immediately sure how to put such a guideline into words.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.