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