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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

(speaking for myself) 

On Wed, 2012-06-20 at 11:32 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 11:45, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> > On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> >>> The most controversial decision was whether the embargo date might be
> >>> extended after it had originally been set.  We resisted these
> >>> suggestions, referring to the process document, which does not
> >>> contemplate extending the disclosure period.  However, when a
> >>> predisclosure list member pressured the discoverer into requesting an
> >>> extension, we felt the best interpretation of the process document
> >>> required us to acquiesce.
> >>>
> >>> Specifically, of course, we as a team would like clearer guidance from
> >>> the process about whether, and if so under what circumstances, a
> >>> predisclosure period should be extended.
> >>
> >> I think this should be done via (perhaps silent) consensus on the
> >> pre-discosure list. Leaving the embargo time line determination
> >> entirely to the discoverer isn't really suitable. He might provide an
> >> initial suggestion, but we ought to set a period of time (say, a
> >> week or less) during which adjustment proposals can be made.
> > 
> > The problem with this is that extending the embargo helps providers
> > who are on the predisclosure list (a minority), but hurts those not on
> > the list (the vast majority).  So there's a moral hazard with what you
> > suggest: it is just way too easy for the people on the list to vote to
> > make their own lives easier, not considering the plight of those who
> > are not big enough or connected enough to be on the list.  Doing so
> > also favors large players and incumbents against small players; doing
> > so may well be considered anti-competitive and illegal in many
> > jurisdictions.
> > 
> > The only way this would work is if the predisclosure list consisted
> > exclusively of software providers, and specifically excluded service
> > providers.  It should be possible to include all software providers on
> > the list, since it's a relatively small number of entities.
> > Furthermore, since software providers presumably care about the
> > security of their customers, it would provide the incentive to make
> > the embargo as short as is reasonable.
> 
> You need to take this in context with my proposal to have only
> software vendors have a vote here, and to allow service
> providers at most an observing (maybe recommending to a
> limited degree) role.

(I'm going to reply elsewhere about my opinions on the existence of the
pre-disclosure list at all, but for the purposes of responding here I'll
assume we are going to keep it)

I think allowing the pre-disclosure list to have any "authority" in any
case would be a mistake. There are certainly scenarios where even a
vendor might want to delay the release for their own purposes. Perhaps
their QA team is too slow, or they want to delay the security update
until they have a new version of their s/w offering ready.

IMHO the predisclosure list should be purely about information flowing
out of Xen.org to the list participants and requests for clarification
going the other way. Membership of the predisclosure list should not
infer any other special privilege or control over the security embargo
process and we need to be explicit about that. Members of the list
*already* have the privilege of being on the list, they should not
expect to also have the privilege of having control over the timelines
etc of individual security vulnerabilities. Influence over the process
should happen during the formulation of the policy -- IOW in public
where everyone, not some select group of downstreams who happen to be on
the list, can have a say.

> 
> >>> 3. Decisionmaking
> >>>
> >>> It was suggested to us several times, and indeed seemed to be regarded
> >>> by some as an underlying principle, that the predisclosure list
> >>> members should be making the decisions about disclosure schedule etc.
> >>>
> >>> The question of who is to make the decisions, and on what basis, needs
> >>> to be addressed.
> >>
> >> See above. Leaving this to the discretion of the discoverer is
> >> neither open nor fair.
> > 
> > But there's a practical matter to consider here: if it's known that we
> > won't cooperate with the discoverer wrt disclosure times, discoverers
> > may simply not share their information with us.  I think that's the
> > main reason for the "do what the discoverer wants" rule.  I think
> > there needs to be some kind of a balance though: extending the embargo
> > less than 12 hours before the deadline is clearly not reasonable.
> 
> I still suggested that the discoverer gets a first shot at the
> embargo deadline. But if everyone else disagrees (i.e. the
> deadline was unreasonable), then it should be possible to ignore
> the discoverer's preference.

We already have wording abut "unreasonableness" but it's not entirely
clear what this means and/or when we would apply it.

I think the default of accepting the disclosers position is a good one.
We want to encourage people to report such bugs to us and taking control
away from them is a good way to discourage them.

Anyhow I'd expect that disclosers wanting to extend the period will be
the uncommon case. More normal would be a discloser who wanted to go
much faster than we do by default (which we can't do anything about and
in any case should respect).

> >>> Several members of the predisclosure list suggested that the
> >>> predisclosure period was too short.  Others were ready within the
> >>> predisclosure period's timeframe, and were disappointed to see it
> >>> extended and to have to delay their fixes.
> >>
> >> Setting a default period might be counter productive. There may
> >> be cases (for example had we wanted to fix XSA-9 properly)
> >> where developing a fix could take quite a bit of time. Not having
> >> a fix ready shouldn't, however, prevent initial announcements of
> >> a problem.
> > 
> > A default period can be considered a guideline.  In the case of a
> > particularly tricky fix, saying, "Normally we would set 2 weeks, but I
> > think in this case we should go for 3 or 4" is perfectly reasonable.
> > 
> > Since the embargo is really for software providers to test fixes,
> > perhaps we should suggest it should be "X business days after a fix is
> > released", rather than "X days after the vulnerability is disclosed"?
> 
> Yes, that sounds like a reasonable thing.

This is probably better, but also ties into the question of public
holidays in various territories. i.e. business day where...

Ian.


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