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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-07-02 at 15:58 +0100, Jan Beulich wrote:
> >>> On 02.07.12 at 15:59, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > 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.
> 
> But in that case, negotiation of an embargo period becomes a
> dead thing altogether - the discoverer saying something, it
> would need to be followed, and in the absence of him stating
> anything defaults would need to be applied. No other option
> would exist, as no-one is given authority.

Hrmm yes. We should certainly make it explicit that in the absence of an
opinion from the discloser the security team can set the time line it
thinks is appropriate, suing the default as a guideline only and
endevouring to keep it as short as possible.

Matt previously posted a link to
https://www.ocert.org/disclosure_policy.html which contains 

"""
   The following time frames regulate oCERT embargo proposals:

   - 7 days, in case the issue is already well narrowed down and
     tested, requiring trivial configuration and/or code change

   - 14 days, standard embargo for most cases

   - 30 days, in case of critical and complex vulnerabilities
     (example, trivial exploitation of administrative privileges on a
     static library affecting a large number of packages), and with
     the agreement of all parties

   - under extremely exceptional circumstances, if the oCERT Team and
     all the parties involved feel the need for longer time, a 2
     months embargo can be applied, in this case we would clearly
     document the decision for public review

   - in any circumstance reporter preference will always be honoured
     in case a joint agreement is not reached, as oCERT would be
     anyway unable to force its embargo
"""

which seems like a reasonable set of rules to me, modulo discussion
about the specific time lines.

>  Giving the security
> team members authority in this respect would already make them
> susceptible to pressure put onto them by other list members.

I think we can a) make it clear that list members don't have that
authority and b) rely on the security team to resist such pressure
better than disclosers and/or other list members.

Ian.



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