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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Jul 2, 2012 at 2:59 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2012-06-29 at 11:01 +0100, George Dunlap wrote:
>> On Wed, Jun 27, 2012 at 7:07 PM, Thomas Goirand <thomas@xxxxxxxxxx> wrote:
>> > On 06/20/2012 05:45 PM, George Dunlap wrote:
>> >> The only way this would work is if the predisclosure list consisted
>> >> exclusively of software providers, and specifically excluded service
>> >> providers.
>> > I agree, though you might have corner cases.
>> >
>> > What if you are *both* software and service provider (eg: I'm working on
>> > Debian and XCP, and my small company provides a hosted Xen service)?
>>
>> If we do make a rule that only software providers can be on the list,
>> and not service providers, then ideally you should try to separate the
>> roles.  If you are on the list as a software provider, you should use
>> that information only to prepare patches; but not deploy them on your
>> own systems until the embargo date.
>>
>> In a way, the question is very similar to asking, "I'm working on
>> Debian and XCP, and my best friend owns a small company that provides
>> a hosted Xen service."  If you told your friend about the
>> vulnerability, you would be breaking the security embargo (and giving
>> your friend an unfair advantage over other hosting services), and
>> would be at risk of being removed from the list if someone found out.
>> If you wear two "hats", as it were, the same would be true if your
>> developer "hat" told your service provider "hat": actually updating
>> your systems before the embargo would (I think) be considered breaking
>> the embargo, and would be giving yourself an unfair advantage over
>> other hosting services.
>>
>> (All of the above discussion is, of course, only valid in the
>> hypothetical situation that we don't allow service providers to be on
>> the list.)
>
> It also supposes that there would be some way to police this separation
> -- how could you tell if a software vendor had given unfair advantage to
> their friends, and how could you tell which one it was in order to
> "punish" them?
>
> The same problem exists if you allow service providers but insist that a
> condition of membership is that they use the pre-disclosure period to
> "prepare but not deploy" (i.e. to keep their hats separate). Other than
> a suspicious wave of reboots across that providers infrastructure
> (attributed to "routine maintenance") how would you know?

I took Thomas' question as, "What is the right thing to do?"  There's
certainly no ability for us to try to police everyone.  In a sense the
pre-disclosure list is already built on trust.  As Alan said, there's
not much we can do legally to enforce a restriction on releasing a
GPL'ed patch; all we can do is remove the offender from the list
post-facto.  And as someone else said, the bigger the company, the
more people may end up hearing about the vulnerability, which
increases the chance that one of them will be using the information
for unapproved purposes (such as writing an exploit for it).

When we have to rely on trust like this:
* I think most people will follow the guidelines if they think everyone else is
* A few "cheaters" are probably inevitable; as long as they're a tiny
minority, things will still work fine
* For those for whom doing the right thing is not a motivating factor,
the risk of being discovered and being excluded , or the risk of a
complete collapse of trust (which in this case would probably make the
pre-disclosure list go away) can make it in their self-interest to
follow the rules.

So I think as long as the expectations are made clear, there is a
chance that an "honor system" could work.

That said, it still introduces unfairness; and will certainly cause
the xen.org security team more headache.  And if your analysis of
blackhat behavior is correct, that releasing a vulnerability by and
large only *reduces* risk, then there's no real need for one.

 -George

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