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

Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217

(speaking for myself)

On Thu, 2012-06-28 at 10:28 +0100, Lars Kurth wrote:
> >>/  1. Purpose of the process/
> >>
> >>/  The first point is that we think the security vulnerability process/
> >>/  document should have an explanation of what its goals are.  This would/
> >>/  have greatly assisted us when making some of the more difficult/
> >>/  decisions./
> >
> > The security vulnerability process document should most definitely
> > encapsulate both explicit guidance and broad tenets that can be used
> > to make tough calls. I think that these should be explicitly called
> > out in front matter as an evolutionary part of the process. Tenets
> > should always be open to being refined or redefined as Xen.org
> > projects grow and usage shifts.
> I wanted to dive a little bit into the purpose of the process as the
> discussion will otherwise get stuck on detail.

Thanks for doing this, I think it was useful.


> Looking at the existing pre-disclosure list shows that it contains
> parties from all groups. This opens Xen.org up to criticism that some
> members of the pre-disclosure have an uncertain advantage, which has
> already been highlighted earlier in this discussion.
> To be honest, I don't really see a way to satisfy all needs:


I think this is the crux of the issue.

Previously I was in favour of the pre-disclosure method but the more I
consider this the more I come to think that it is not the one best
suited to Xen or of the greatest overall benefit to all Xen users.

Pre-disclosure might be appropriate for projects whose downstreams are
generally software providers (e.g. Linux distros) but the high
proportion of Xen's immediate downstreams who are service providers
makes the balance somewhat different. In the case where you have a high
proportion of downstreams who are service providers the inherent
unfairness of pre-disclosure lists amplified since membership of the
pre-disclosure list allows those service providers to begin deploying
the fix without breaching the embargo, which is even more of an
advantage than just knowing about the issue and being able to prepare an
update for your users.

With that in mind I'm inclined to suggest that Xen.org would be better
off publishing security vulnerabilities publicly immediately once we
have a fix ready and tested/validated. This should be done ASAP and
ideally within a couple of weeks of being informed by the discloser (but
if we need longer we should take it to be sure we get it right). Before
that point only persons who need to know in order to contribute to the
fix should be given knowledge of the vulnerability.

This is basically the only way which is properly fair, since everyone
starts out on the same footing.

As soon as you have a pre-disclosure list you have to start dealing with
issues of fairness, who gets to be on the list, anti-competitiveness,
dealings between pre-disclosure members, issues of revoking and
reinstating privilege at which point you end up with complex policies
and associated bureaucracy. And at the end what you have still won't be
fair, because it can't be unless you let everyone in.

I don't think doing things this way any particular impact on "days of
risk", vulnerabilities basically fall into two sets wrt Blackhat's
knowledge about them AFAICS:

a) they are already known to the blackhats, who are either exploiting
them or not. Either way as soon the vulnerability is published they will
throw it away and start using some other zero day. Even if they do
continue to use it for a little while this is no different to them
continuing to exploit it during the embargo period. Either way our going
public without an embargo period hasn't helped them.

b) the don't know about it, but as soon as the vulnerability is
published it becomes uninteresting to them, they can either race with
the ongoing deployments to develop an exploit or they can continue to
use some other zero day exploit which we don't know about yet. This does
open a small potential window but the motivation for blackhats to start
developing an exploit for something which is already being actively
closed down seems to me to be quite small. This window is not
appreciably different to the window after the embargo period ends.


Xen-devel mailing list



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