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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

>> 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.

>> 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"?

> As to downstreams, I think only direct ones should be involved in
> any decision making processes. Indirect ones might be allowed on
> the list, but exclusively as observers. Mis-use of the observer role
> (e.g. as in influencing those participating in decision making in
> undue ways), should it become known, should result in removal of
> list membership.

What do you mean by "direct" and "indirect"?  If by "direct" you mean,
"sell/distribute software", and "indirect" you mean, "use the software
to provide a service", I think we're probably in agreement. :-)

-George

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