From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Security vulnerability process, and CVE-2012-0217 Date: Fri, 6 Jul 2012 18:24:56 +0100 Message-ID: <4FF71F68.2030708@eu.citrix.com> References: <20448.49637.38489.246434@mariner.uk.xensource.com> <4FEB4BDD.5040205@goirand.fr> <4FEC23B7.7020802@xen.org> <20120703220337.GC4332@US-SEA-R8XVZTX> <4FF45896020000780008DA4C@nat28.tlf.novell.com> <81A73678E76EA642801C8F2E4823AD21DAA1202DB3@LONPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <81A73678E76EA642801C8F2E4823AD21DAA1202DB3@LONPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Matthew Allen Cc: Jan Beulich , Stefano Stabellini , Lars Kurth , Matt Wilson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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