[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
>>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |