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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.17 at 12:27, <george.dunlap@xxxxxxxxxx> wrote:
> On Wed, Jan 4, 2017 at 2:48 PM, George Dunlap <george.dunlap@xxxxxxxxxx> 
> wrote:
>> On Wed, Jan 4, 2017 at 1:16 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 04.01.17 at 13:36, <george.dunlap@xxxxxxxxxx> wrote:
>>>> 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 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.
>>>
>>> Both positively identifying an OS and proving a particular OS is
>>> unaffected will be kind of hard for closed source OSes. Hence I
>>> think ...
>>>
>>>> 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.
>>>
>>> ... that for a bug to not be a vulnerability, at the very least
>>> Windows would need to be proven to be unaffected. If in
>>> doubt, an advisory should be issued.
>>
>> Quite a bit about Windows' internals are understood, by people who
>> write drivers, by people who have access to the source code, by people
>> who observe Windows' behavior as a guest, and so on.  So I expect that
>> with the expertise of the organizations in the security team at the
>> moment, in practice we would have a pretty good idea whether Windows
>> would be vulnerable or not.  I just didn't want to make any promises,
>> since (as you say) we can't look at the source code ourselves.  I
>> think we should make a reasonable effort to ascertain whether Windows
>> is vulnerable; but I think we only need to be "reasonably certain"
>> that Windows is not vulnerable.
> 
> I think so far the only concern raised.  I mainly worded it the way
> that I did to "balance what we can promise and what we would like to
> deliver" -- that is, it promises that we will look at open-source
> operating systems, and implies that we will make a best-effort to look
> at Windows as well.
> 
> Jan, are you happy with the wording the way it is?  If not, could you
> make some concrete suggestions for how you think it could be improved?

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

Jan


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