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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-07-03 at 23:03 +0100, Matt Wilson wrote:
> On Thu, Jun 28, 2012 at 02:28:23AM -0700, Lars Kurth wrote:
> > On Sat, 23 Jun 2012 12:42:14 -0700, Matt Wilson <msw@xxxxxxxxxx> wrote:
> > > On Tue, Jun 19, 2012 at 11:16:05AM -0700, Ian Jackson wrote: 
> > > >/  1. Purpose of the process/
> > > >
> > > >/  The first point is that we think the security vulnerability process/
> > > >/  document should have an explanation of what its goals are.  This 
> > > >would/
> > > >/  have greatly assisted us when making some of the more difficult/
> > > >/  decisions./
> > >
> > > The security vulnerability process document should most definitely
> > > encapsulate both explicit guidance and broad tenets that can be used
> > > to make tough calls. I think that these should be explicitly called
> > > out in front matter as an evolutionary part of the process. Tenets
> > > should always be open to being refined or redefined as Xen.org
> > > projects grow and usage shifts.
> > 
> > I wanted to dive a little bit into the purpose of the process as the
> > discussion will otherwise get stuck on detail. Also into the actors
> > in a security vulnerability and their interest.
> > 
> > 1.1: The Xen.org Security team, whose task is to administer the process
> > and act as referee if needed: the process should provide clarity and
> > ensure that the team can be seen as referee. The process needs to be
> > clear enough to avoid a chance that members of the team are accused of
> > being partial.
> > 
> > 1.2: Discoverer of the vulnerability: The process must provide an
> > incentive for the discover to report the issue to the project. If we
> > get the process wrong, the consequence will be that vulnerabilities
> > will not be reported to us. That would be detrimental to all
> > stake-holders as it will increase days-of-risk for everybody else.
> > E.g. if the embargo period is too long. Not sure what other factors
> > motivate a discoverer.
> 
> I agree. The process should align with the common goal, shared among
> all the groups that you've identified, of improving security. We can
> only expect to attract disclosures from discoverers that agree that
> "coordinated disclosure" (or "responsible disclosure" if the term is
> acceptable) improves security for everyone.
> 
> We can't expect to attract discoverers that feel that "full
> disclosure" is the best way to improve security,

I don't think this is necessarily true. There is a spectrum between
"full disclosure" and "coordinated". Part of the purpose of giving the
discloser the final say on timelines is precisely to allow people who
hold views towards the full end of the spectrum to feel comfortable
coming to us. If they want to do immediate disclosure then that is what
we will do, per the current policy at least, and I think this property
needs to be retained.

Having such full disclosure come through the proper Xen communication
channels in a timely manner is clearly preferable to having it be
published on some security researchers blog or in a paper which many of
our users may never read and which we ourselves may not find out about
until some (hopefully short, but non-zero) time later.

Now maybe not all such people will want to come to us, some will
obviously just publish without any warning, but we should make it clear
that if they come to us we will respect their wishes here so that some
may feel comfortable giving us a heads up. Even if they say "I'm
publishing this in 1 hour" that will allow us to at least do
*something*, e.g. repost their disclosure and make people aware while we
develop the fix.

>  nor can we expect to
> attract discoverers that want to be compensated through either black
> markets or white markets for zero-day exploits.
> 
> I think that 1) calling out the important role of the discoverer in
> the process, and 2) stating that proposed disclosure time lines are
> negotiable should be sufficient in retaining discoverers that choose
> to participate in coordinated disclosure. Also, a track record of
> rapidly addressing reported vulnerabilities should help.
> 
> For further reading, a fairly detailed exploration of the motives of
> discoverers is covered in a paper by Stefan Frei et al., "Modelling
> the Security Ecosystem - The Dynamics of (In)Security". [1]
> 
> > 1.3: Developers within the project, who will be task to find a fix
> > as quickly as possible.
> > 
> > 1.4: 3rd parties that may need to be contacted in order to develop a
> > fix to understand the issue and advise the security team (in the case
> > of CVE-2012-0217 hardware vendors).
> > 
> > 1.5: Developers of downstream projects/distros consuming Xen and
> > distributing it (FOSS or commercial), who will apply the fix to
> > their project/distro.
> 
> The distinction between 1.5 and 1.6 isn't always clear. For example,
> Amazon Web Services builds a Linux image for use in EC2 called the
> Amazon Linux AMI [2]. Some of the issues coordinated through
> security@xxxxxxx may involve the domU side of PV drivers. The fix will
> need to be applied to the kernel in the AMI, just as it would need to
> be applied to Debian, Ubuntu, Fedora, RHEL, SLES, etc.

Fixes to Linux (even ones relating to Xen) should IMHO go via the Linux
security process, not the Xen.org one, since Linux is not a Xen project.
Presumably all those distros etc are set up to deal with that channel in
the appropriate manner.

Similarly we would not expect to release e.g. *BSD updates via this
process -- those would be done by the relevant OS vendor following their
normal processes.

We could (and probably should) consider writing into the policy that we
will communicate Xen related security updates which come out of other
projects (*BSD, Linux, qemu etc) to our users. i.e. forwarding them to
our relevant lists.

> Additionally, members of group 1.6 may have the same amount of
> porting, building and validation work to do as a traditional Linux
> "distro" when addressing an issue in the hypervisor, dom0 or related
> sub-component.
> 
> > 1.6: Other direct consumers of Xen (e.g. service providers). Their
> > main goal of the process would be to reduce days-of-risk for
> > themselves. The issue being that deploying a fix can take a long time.
> > Another issue is that providing a fix before somebody else is a
> > competitive advantage.
> 
> The notion that service providers are only concerned with reducing
> risk for themselves seems short sighted. In my view, the real concern
> is to reduce days-of-risk for everyone that relies, in any way, on the
> infrastructure supplied by IaaS providers. That includes a service
> provider's direct customer, and that customer's users or customers,
> and so on.

I think that by themselves Lars was suggesting that IaaS providers are
general most interested in their own direct customers, that customer's
user or customers etc. They aren't necessarily interested in days of
risk for some other IaaS providers customers, their customer's customers
etc.

This is especially relevant when some IaaS providers are not eligible to
be on the predisclosure list. As we have seen in this most recent
embargo members of the predisclosure list are quite willing to lobby for
extensions to the embargo for their own benefit (or at best the benefit
of only the pre-disclosure members) despite the fact that this leaves
everyone else (the "silent majority") vulnerable, and unknowingly so,
for longer.

[...]

> > Looking at the existing pre-disclosure list shows that it contains
> > parties from all groups. This opens Xen.org up to criticism that some
> > members of the pre-disclosure have an uncertain advantage, which has
> > already been highlighted earlier in this discussion.
> 
> I think that reworking the membership criteria and a transparent
> membership request process, similar to how subscribe / unsubscribe
> requests to the "distros" and "linux-distros" mailing lists [3], can
> solve this. Or, address it as well as the distro lists have.

Do you have any specific criteria in mind for membership?

linux-distros is "membership limited to operating system distribution
security contacts".

Which of groups 1.5, 1.6 and 1.7 should be allowed? I think that unless
we open this list to anyone in 1.6 and 1.7, regardless of size or other
factors, the pre-disclosure concept is unworkable.

Ian.



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