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

[Matthew Allen <matthew.allen@xxxxxxxxxx>]

(Full disclosure: I am part of the Citrix security team on the present 
pre-disclosure list)

On 06/20/2012 02:16 AM, Ian Jackson wrote:
> The first point is that we think the security vulnerability process 
> document should have an explanation of what its goals are.
Then we need consensus on the goals before we get too far into the details of 
the process.
Otherwise we don't have anything against which to measure the options.

and on 06/28/2012 10:28 AM, Lars Kurth wrote:
> Of course the ultimate goal of the process should be to minimize 
> days-of-risk for everyone. To do this, the process has to balance the 
> following factors to reduce days-of-risk [...]

This also seems an obvious goal to me; is there consensus that this _is_ a 
goal, and are
there suggestions for other goals?

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'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.  You can disregard this as "not an open-source 
problem",
but I would claim that a viable commercial use of Xen also benefits the 
open-source
community.  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!

Matthew

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