Re: [Xen-devel] Security discussion: Summary of proposals and criteria

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Fri, Jul 13, 2012 at 5:18 PM, Matt Wilson <msw@xxxxxxxxxx> wrote:
>> One thing we all seem to agree on is that with regard to the public
>> disclosure and the wishes of the discloser:
>> * In general, we should default to following the wishes of the discloser
>> * We should have a framework available to advise the discloser of a
>> reasonable embargo period if they don't have strong opinions of their
>> own (many have listed the oCERT guidelines)
>> * Disclosing early against the wishes of the disclosure is possible if
>> the discloser's request is unreasonable, but should only be considered
>> in extreme situations.
>
> I agree with the first two bullets. On the third, I think that it is a
> very unusual circumstance for a discoverer to make a request that is
> categorized as unreasonable by the security process. For example, I
> think that it is reasonable for a discoverer to request that a
> different group take over the coordination of an issue if it is
> discovered that the vulnerability reaches beyond Xen projects. Should
> this occur in the future, I think that Xen should honor the request
> and work with the new coordinator.

It sounds to me like you fundamentally agree with the concept, but
just want to be clear exactly what "extreme" and "unreasonable" means.

WRT this particular situation: Realizing that the vulnerability
extended beyond the Xen community and wanting to pass it on to someone
else to coordinate all related projects is certainly an understandable
thing to do.  However, as I understand it, that's not actually what
happened in this case.  Originally the release date for Xen was set
for a certain date; the discloser asked the date to be changed within
12 hours of the original disclosure date.  And the reason for the
change was not because they wanted to bring in other projects, but
because one particular member of the list mounted an intense campaign
to have it extended.  The reason that member mounted the campaign was
not because they were concerned with other projects, but only because
they themselves had (as I understand it) not paid attention to the
initial announcement (as an organization) and thus didn't have enough
time to patch their systems before the end of the embargo period.  If
that organization had been paying attention, they would not have
mounted the campaign, and the Xen vulnerability would have been
disclosed without reference to any other projects.

(Also, if that organization had been paying attention, we would not be
having this discussion right now, as no fault would have been found
with the status quo.)

> I think that we should attempt to come to some consensus before taking
> a straw poll. There are too many options below, and I think that we
> should be able to eliminate some of them through open discussion.

Well, it's clear that we do not have consensus.  What I had in mind
was actually a particular kind of poll designed to help focus the
discussion on points that are actually important.  It's called
"Identify the Champion", and I've seen it used really well on program
committee meetings.  (http://scg.unibe.ch/download/champion/)

The basic idea is this:  For each of the items below, people respond
in one of 4 ways:
* This is an excellent idea, and I will argue for it.
* I am happy with this idea, but I will not argue for it.
* I am unhappy with this idea, but I will not argue against it.
* This is a terrible idea, and I will argue against it.

If we find that there is one option no one will argue against, then we
can take a real vote on that option.  If not, we can discard ideas no
one is arguing for with no further discussion, and focus on the areas
where there is disagreement.

Does that make sense?

>> In all cases, I think that we can make a public announcement that
>> there *is* a security vulnerability, and the date we expect to
>> publicly disclose the fix, so that anyone who has not been disclosed
>> to non-publicly can be prepared to apply it as soon as possible.
>
> I've not seen this path taken by other open source projects, nor
> commercial software vendors. I think that well written security
> advisories that are distributed broadly (i.e., sent to bugtraq,
> full-disclosure, oss-security, and regional CSIRTs if warranted) are
> effective alert mechanisms for users. As an aside, JPCERT/CC published
> some nice guidelines for software providers on how best to format
> advisories:
>   http://www.jpcert.or.jp/english/vh/2009/vuln_announce_manual_en2009.pdf

OK -- well this is a detail I think we can work out after we address
the main point.

> I think that option 1 effectively abandons much of the benefits of a
> coordinated/responsible security disclosure in an open source
> context. I don't think that a patch from Xen.org provides an
> immediately consumable remediation for a security issue that users
> need.
>
> Of the remaining options, to me it seems that a refinement of the
> status quo is in order. I don't think that the current policy is
> fundamentally flawed. If we approach the problem the same way as code,
> wouldn't an iterative approach make sense here rather than a rewrite?
>
> I'll say again that I think that the "software provider" versus
> "service provider" distinction is artificial. Some software providers
> will undoubtedly be using their software in both private and public
> installations. Some service providers will be providing software as a
> service.

Well, no, it's not at all artificial.  There is a *very big*
difference between software providers and service providers, and it's
who their customers are and what they want.  That has a very large
impact on their incentives, as well as actual cost.

What you want is not to blur the distinction between "software
provider" and "service provider"; what you want is to make an
additional distinction between users: "vendor-supplied" users, who
simply take binaries directly from a software provider, and
"self-supplied" users, who do their own development based on upstream
sources.

So it's true that both "software providers" and "self-supplied users"
both do development, the effect of the disclosure on both is very
different.  I had intended to make this clear in my analysis; but
there are so many factors now I'm not sure the analysis will not
collapse under its own weight. :-)

> However, one development during the past 12 years of arguing is the
> idea of responsible/coordinated disclosure as a middle ground for
> addressing vulnerabilities in a more controlled way. By and large I
> think that coordinated disclosure is the best approach available, and
> we should look to incorporate established best practices by other
> organizations who have traveled this road before us.

Well one very large organization (Linux) has decided not to have any
pre-disclosure; so no matter what we choose, there are precedents. :-)

> I think that any concerns about fairness should be raised now by the
> parties that feel they are impacted, as part of the open discussion,
> rather than as speculation.

Well, many already have been raised, both on the list and in
discussions with individuals.

>> Another question has to do with robustness of enforcement.  If there
>> is a strong incentive for people on the list to break the rules
>> ("moral hazard"), then we need to import a whole legal framework: how
>> do we detect breaking the rules?  Who decides that the rules have
>> indeed been broken, and decides the consequences?  Is there an appeals
>> process?  At what point is someone who has broken the rules in the
>> past allowed back on the list?  What are the legal, project, and
>> community implications of having to do this, and so on?  All of this
>> will impose a much heavier burden on not only this discussion, but
>> also on the xen.org security team.
>
> I think that before we become too concerned about rules and
> enforcement, we should have a better sense of what rules are in the
> best interest of the largest population of users possible. I don't
> feel that we've discussed this enough.
>
> You're right that there's likely no solution that everyone is going to
> feel is "fair." But we should be able to come up with a proposal that
> everyone agrees improves security for the most users.
>
> This is a trade-off that is made constantly in coordinated response
> activities. If there's a commonly embedded bit of code, for example
> zlib, that many software vendors ship in their products, it will be
> impossible to do a coordinated disclosure among every single one of
> them. Typically a response is coordinated among as many parties that
> can be reasonably handled while preserving some confidence that leaks
> will be minimized.
>
> For a recent example of this, see the LWN article on the DES-based
> crypt() coordination posted last month: http://lwn.net/Articles/500444/
>
>> I think those cover the main points that have been brought up in the
>> discussion.  Please feel free to give feedback.  Next week probably I
>> will attempt to give an analysis, applying these criteria to the
>> different options.  I haven't yet come up with what I think is a
>> satisfactory conclusion yet.
>
> Thanks again for writing this up. I'm looking forward to your analysis.
>
> By the way, I'll be at OSCON next week. I'd love to meet up and talk
> in person.

That would be great. :-)

 -George

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