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

[Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>]

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

Reality check. If the reporter decides to give you a date you are given a
date, if they decide to not negotiate that date then you can either meet
it or leave your customers vulnerable when it is published.

A lot of reporters are hostile to extensions and slowness because there
is a long history of process abuse elsewhere.

> I think having hardware vendors involved is really only necessary
> when hardware related issues need to be dealt with.

Which can be done on a case by case basis.

> As indicated above, this should not be permitted, due to
> fairness considerations. Otherwise we should not place
> restrictions on who might be on the list at least as an observer.

For any GPL code elements you cannot create a contractual basis for
preventing code release. It's a violation of the GPL "additional
restrictions" rule. At best you can trust everyone to be sensible.

> Just the same we allow individual vendors to communicate -
> acknowledge the fact that there is a vulnerability, identifiers, and
> expected embargo deadline.

You also need to end it the moment a third party publishes any info, or
you'll get into stupid situations where only those who signed up to it
can't talk about it (eg the infamous pentium lockup bug)

> > 8. Predisclosure subscription process, and email address criteria

Email is not a trustworthy medium. The linux security list  was in the
past intercepted.

> > We need a clear policy about releasing proof of concept exploits -
> > whether, when and who to.
> 
> This I think could (and perhaps should) be really be left to the
> discoverer, as this may be considered intellectual property.

They ought to be in the regression suite if possible.

On the fixes side also remember some vendors may choose to ship fixes
that differ from the "official" one.

Alan

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