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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Sat, Jun 23, 2012 at 8:42 PM, Matt Wilson <msw@xxxxxxxxxx> wrote:
> But taking a step back, I propose that a core tenet of the security
> response process should be to reduce days-of-risk for all consumers of
> Xen.org projects, whether direct or indirect, to zero. Days-of-risk
> can be fuzzy to measure, so we could define this as the number of days
> between when a security problem is publicly known (e.g. through
> evidence of exploitation in the wild or a public announcement) and
> when the problem has been addressed such that there is no longer any
> risk (e.g., through a Xen consumer deploying a fixed version from a
> vendor or an infrastructure provider doing the same on a consumer’s
> behalf.)

Minimizing overall risk for all users of Xen certainly is the end goal
of the "responsible disclosure" process.  However, there seem to be
two flaws in the way you are defining "days-of-risk" (from how you
seem to be using and arguing about the term):
* It assumes risk on any given day is 0 or 1
* It assumes that, in the absence of evidence to the contrary, risk is
0 until the vulnerability is published by members of the
pre-disclosure list.

If those two things were true, then your policy recommendations below
might make sense.

Unfortunately, neither are true.  The real risk begins the date
software with that vulnerability is *deployed*.  From that time
software with a vulnerability is first *deployed* until the time
software with the fix is deployed, every user of that software is at
risk.  Any black hat could have been looking at the code and wondering
the same thing that the original reporter was wondering.  In this case
even more so, because Linux introduced a patch to fix the
vulnerability for them in 2006.  There must have been any number of
black hats who looked at that vulnerability and wondered if other
operating systems were vulnerable, and discovered that they were.  So
having "0 days-of-risk" for a vulnerability disclosure process is, by
definition, impossible.

Now clearly, the risk greatly increases when the vulnerability is
announced.  But any discussion of whether, and which service providers
may be included in the vulnerability disclosure process must
acknowledge that:
1. *All* service providers, and indeed all users whether they provide
service or not, are at risk every hour that a fix is not deployed on
their systems
2. Any disclosure which allows some users to patch before others gives
an advantage to those users (whether by allowing them to actually
patch their systems before the embargo period, or allowing them to
prepare the patching system so that they can be down within an hour)

And I'm going to suggest something else which I think is true, and
relevant to the discussion:
3. A large majority of deployed Xen instances are run by people not on
the pre-disclosure list.

>> Of course this needs to deal clearly with the common stituation of an
>> organisation running Xen which is a direct consumer of Xen.org source
>> code.
>
> Indeed. If a goal of the process is to reduce days-of-risk for all
> consumers of Xen.org projects to zero, coordinating package updates
> only from software vendors will not achieve it.

But "coordinating package updates only" may minimize the total risk to
all users, by allowing more users to deploy sooner.

> This may be a reasonable starting point for general issues, but I
> think that the overall impact and complexity of an issue needs to be
> considered when establishing a timeline.

I guess in part it means on what you mean by "complexity of the issue":
* In this particular case, we ended up having to coordinate with other
vulnerable projects; that is rather an exception to the rule, and
should of course have special consideration.  (Although, I might argue
that we should have told the other projects, but simply not mentioned
in our disclosure that they may be vulnerable -- i.e., make the
announcement similar to Linux's 2006 reporting of the same
vulnerability.)
* You may mean "difficulty in coming up with a fix".  I think this can
be addressed by setting the disclosure period from the time that a
*fix* is available, not the time the vulnerability is known.
* You may mean, "difficulty in deploying the fix".  In this case, it
was a simple case of recompiling the hypervisor and rebooting* -- as
such, the deployment is probably as simple as it will ever get.

(* The complexity of doing unsupported things, like hot-patching the
hypervisor, shouldn't be considered IMHO.  If hot-patching is
valuable, work should be done to make that a supported feature.)

> Parties that are *active* in the coordinated disclosure, for example
> by building patched versions of products or services built on Xen,
> need to have access to as much technical information as possible in
> order to validate the fix and their ports. Those that are passive, who
> may be deploying a pre-release fixed version from a vendor, do not
> need access to these materials.

I think this distinction is important to consider.

This is not to you, but to everyone:  Can I suggest that as much as
possible, we don't use poorly-defined terms like "direct" and
"indirect"?  As far as I know we have the people listed below; we
should try to come up with clear terms for each of them.

* Software vendors, who take upstream Xen and package it into
something else and provide that software to users
* Users
 - "Private" users, who take Xen in some form and use it for themselves
 - Service providers, who use Xen to provide
infrastructure-as-a-service to others. (I think that's the right
*AAS...)
 - Service clients, who buy IAAS services from service providers.

The "Users" group can also be divided another way:
* Those that only consume software vendors' updates
* Those that apply their own patches to xen.org (or software vendors' updates)
I don't think "passive" and "active" users really conveys the right
idea, but it will have to do for now.

So the question is: given that we can't have all active users on the
pre-disclosure list, what justification is there for having some of
them on the list?

 -George

(I think we should pretty much assume that unless explicitly stated,
all opinions are the opinions of the individuals, not the
organizations they work for.)

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