From: George Dunlap <george.dunlap@eu.citrix.com>
To: Matthew Allen <matthew.allen@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
Lars Kurth <lars.kurth@xen.org>, Matt Wilson <msw@amazon.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Security vulnerability process, and CVE-2012-0217
Date: Fri, 6 Jul 2012 18:24:56 +0100 [thread overview]
Message-ID: <4FF71F68.2030708@eu.citrix.com> (raw)
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21DAA1202DB3@LONPMAILBOX01.citrite.net>
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
next prev parent reply other threads:[~2012-07-06 17:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 18:16 Security vulnerability process, and CVE-2012-0217 Ian Jackson
2012-06-20 8:49 ` Jan Beulich
2012-06-20 9:45 ` George Dunlap
2012-06-20 10:32 ` Jan Beulich
2012-07-02 13:59 ` Ian Campbell
2012-07-02 14:58 ` Jan Beulich
2012-07-02 15:04 ` Ian Campbell
2012-07-02 15:17 ` Alan Cox
2012-07-02 15:20 ` Ian Campbell
2012-06-28 18:30 ` Alan Cox
2012-07-04 9:27 ` Ian Campbell
2012-07-04 10:04 ` John Haxby
2012-06-29 10:26 ` George Dunlap
2012-06-29 10:41 ` Jan Beulich
2012-07-02 14:00 ` Ian Campbell
2012-06-23 19:42 ` Matt Wilson
2012-06-28 17:45 ` George Dunlap
2012-07-02 13:59 ` Ian Campbell
2012-06-27 18:07 ` Thomas Goirand
2012-06-27 19:14 ` Alan Cox
2012-06-27 19:30 ` Sander Eikelenboom
2012-06-28 9:28 ` Lars Kurth
2012-07-02 13:58 ` Ian Campbell
2012-07-02 14:51 ` Jan Beulich
2012-07-02 14:57 ` Ian Campbell
2012-07-03 22:03 ` Matt Wilson
2012-07-04 10:33 ` Ian Campbell
2012-07-04 11:24 ` Stefano Stabellini
2012-07-04 12:36 ` George Dunlap
2012-07-04 12:52 ` Jan Beulich
2012-07-04 12:56 ` George Dunlap
2012-07-04 13:01 ` Jan Beulich
2012-07-04 13:30 ` Stefano Stabellini
2012-07-04 14:09 ` Jan Beulich
2012-07-04 15:09 ` Stefano Stabellini
2012-07-06 14:36 ` John Haxby
2012-07-06 16:39 ` Matthew Allen
2012-07-06 17:24 ` George Dunlap [this message]
2012-06-29 10:01 ` George Dunlap
2012-06-29 15:48 ` Thomas Goirand
2012-07-02 13:59 ` Ian Campbell
2012-07-02 15:13 ` Alan Cox
2012-07-03 11:12 ` George Dunlap
2012-07-03 14:18 ` Stefano Stabellini
2012-08-23 10:37 ` Ian Campbell
2012-08-23 10:37 ` [PATCH 1/6] Clarify what info predisclosure list members may share during an embargo Ian Campbell
2012-08-23 10:37 ` [PATCH 2/6] Clarifications to predisclosure list subscription instructions Ian Campbell
2012-08-23 10:37 ` [PATCH 3/6] Clarify the scope of the process to just the hypervisor project Ian Campbell
2012-08-23 10:37 ` [PATCH 4/6] Discuss post-embargo disclosure of potentially controversial private decisions Ian Campbell
2012-08-23 10:37 ` [PATCH 5/6] Patch review, expert advice and targetted fixes Ian Campbell
2012-08-23 10:37 ` [PATCH 6/6] Declare version 1.3 Ian Campbell
2012-09-24 11:25 ` Security vulnerability process, and CVE-2012-0217 [vote?] Lars Kurth
2012-10-01 16:38 ` Ian Jackson
2012-10-03 17:03 ` Lars Kurth
2012-10-04 8:39 ` Lars Kurth
2012-07-02 15:24 Security vulnerability process, and CVE-2012-0217 John Creol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FF71F68.2030708@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=lars.kurth@xen.org \
--cc=matthew.allen@citrix.com \
--cc=msw@amazon.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.