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

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

On 06/07/12 17:39, Matthew Allen wrote:
One question I've got is how we measure days-of-risk for everyone in order to 
them?  From a Citrix point of view we'd see that as (time between it being 
probable that
an exploit is used and a fix being deployed) x (number of affected 
individuals).  We'd
then expect that a pre-disclosure list would reduce that number.

I've just sent an e-mail with a discussion of risk (among other factors). I think a more accurate formula would be SUM[over days](probability of exploit * number of affected individuals); or, to simplify things, the total risk is the sum of "private vulnerability" (time before the public disclosure) and "public vulnerability" (after the disclosure but before users can roll out fixes).

As I say in that e-mail, one might expect that pre-disclosure would reduce that number. But I'm of the opinion that in fact it will not. Most of the people advocating pre-disclosure seem to think that "probability of exploit" is very low before public disclosure, and very high afterwards. I don't think that's true; at very least, the "probability of exploit" during the "private vulnerability" period is a serious risk. Any pre-disclosure period will extend that time, thus extending the risk.

I'd also like to add to Lars' list of factors (incentive to disclose, times to 
reducing leaks and being fair) with another issue: the quality of the fix.  
ISTM that the
Xen.org security team did a superb job in getting out an initial fix for a 
complex set of
problems within the one week target of the present policy, but (again from a 
Citrix pov)
I'd rather have more time spent to get a greater assurance of a complete fix.  
That means
that not only has the identified issue been comprehensively fixed but similar 
issues in the
code have been looked for (fixing a single unchecked memcpy and publicising it 
_increases_ actual risk if there are more in the code).
Having a good quality fix can be done by allowing more time or (as has been 
having more people involved; I don't think we'd have a strong view on which 
route was
chosen but if it's the latter, Citrix would be willing to help where requested 
and appropriate.

My other concern is the time available to apply the fix once available.  It 
really does take
time to test a fix to a level that companies will trust their business, 
particularly if you're
supporting multiple versions.
This is certainly true. Not having a predisclosure list does mean that customers of "high value" software vendors, such as SUSE, Oracle, and Citrix, may spend an amount of time "publicly vulnerable" while those vendors prepare fixes (but don't forget, with pre-disclosure, they will have at least that much time "privately vulnerable"). Since these "high value" software vendors contribute nearly all the resources for xen.org, I think it's fair to take their needs into consideration.

It may be true, as you say, that because (say) Oracle will do more testing than (say) Debian, that Oracle's users will be publicly vulnerable for longer than Debian users, and both may be vulnerable longer than users who download directly from xen.org. However, to a certain degree that's probably fair -- the cost of being publicly vulnerable for longer is paid for by the confidence that the update will not cause problems when they roll it out. Having a pre-disclosure period means that users who download directly from xen.org have significantly longer "private vulnerability", but without getting any advantages in terms of reliability of the patch.
I'd therefore particularly endorse the idea that, rather than having a single
fixed timescale, the timing should depend on the severity particular issue(s).  
  We also
need to be clear where backporting happens in the timescales; I suspect that a 
proportion of Xen users aren't on xen-unstable and rather than that being a bad 
thing I'd
claim that it's evidence of Xen's widespread adoption and success!
I would expect that if we chose to do away with the pre-disclosure period, the xen.org security team would also release backports to still-maintained releases; in this case, at least 4.1, 4.0, and 3.4. This will hopefully reduce most vendors' time creating a fix to testing.


Xen-devel mailing list



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