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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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 
> minimise
> 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 
> fix/apply/deploy,
> 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 
> probably
> _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 
> suggested)
> 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 
> significant
> 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.
 -George

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