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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Wed, Jan 25, 2017 at 8:40 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 24.01.17 at 17:33, <George.Dunlap@xxxxxxxxxx> wrote:
>>> 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?
>
> Sounds all reasonable.
>
>> But I’m not immediately sure how to put such a guideline into words.
>
> Same here; all I really would like to avoid is for Windows (as
> presumably the most relevant closed source OS we care
> virtualizing) to be completely left out of the picture here.

OK, I've rewritten the section thus:

---

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 vunlerable".  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, 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 make
an effort to investigate the vulnerability of Microsoft Windows.  If
we are reasonably certain that none of these operating systems are
vulnerable, and there are no other operating systems known to be
vulnerable, then no advisory will be issued.

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

---

Essentially, the promise is that we will investigate Windows (along
with others), and issue an advisory unless we are "reasonably certain"
that none of them are vulnerable.

If there are no objections to this I'll write up a second version and
put it in a blog post in a few days here to make sure it gets broader
visibility within the community.

 -George

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