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

[Matt Wilson <msw@xxxxxxxxxx>]

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

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.

> 1.7: Indirect consumers of Xen. With all the same motivations than
> direct consumers.
> 
> A couple of observations:
> 1) The further you get down the list, the more people are involved,
> the greater the risk that information will leak.

I mostly agree, so long as 1.1 (security@xxxxxxx) and 1.2 (discoverer)
are reversed.

> 2) Groups 1.1 - 1.4 necessarily need to be involved to create a fix,
> as otherwise there won't be a fix for the other groups.
> 3) Groups 1.6 - 1.7 are directly impacted by days-of-risk
> 4) Groups 1.1, 1.3 & 1.5 are impacted insofar that the reputation
> of their organisation may be damaged if the situation is not handled
> well.

Group 1.6 may also have reputation impacts.

> Of course the ultimate goal of the process should be to minimize
> days-of-risk for everyone. To do this, the process has to balance the
> following factors to reduce days-of-risk
> 
> A) Provide incentive for vulnerabilities to be reported to Xen.org
> security team in the first place
> B) Time it takes to develop a fix
> C) Time it takes downstream projects/distros to apply it
> D) Time it takes to deploy fixes for consumers (1.6 & 1.7)

See my comment above about fix integration for group 1.6.

> E) Reduce the possibility of a leak (keep pre-disclosure list small)
> F) Avoid the perception that members of the pre-disclosure list have
> an unfair advantage
>   
> 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.

> To be honest, I don't really see a way to satisfy all needs:
> - Restrict membership of disclosure lists to stake-holders 1.1, 1.2,
>    1.3 and 1.5 with members of 1.4 drawn in as needed and full public
>    disclosure afterwards as to who was consulted.

Indeed, this won't satisfy the needs of group 1.6 if my comments above
are generally accepted.

> - Of course it may be desirable to get advice from members of groups
>    1.6 and 1.7. Or is it? If it is, a different approach may be to have
>    a merit rather than size based selection criteria for members of 1.6
>    and 1.7 (e.g. something along the lines of "contributions" to the
>    community, but that would need to be measurable - or even some sort
>    of elections). But it is hard to see how this would work in practice.
>    Of course such an would have the advantage that a member of that group
>    that used mbership to gain an unfair advantage over others could be
>    removed from the pre-disclosure list.

I think that feedback and testing from members of the pre-disclosure
list has been beneficial in the past and is desirable.

> - Another possible approach may be a two-stage pre-disclosure
>    - Stage 1: Groups 1.1, 1.2, 1.3 and 1.5 with 1.4 as needed
>    - Stage 2: Groups 1.6 and 1.7 (with a relatively weak membership
>      criterion such as being a service provider - but then how does
>      this differ from being public and who would administer?)

I don't think that this is substantially different than the first
approach.

> - Another option may be to delegate more difficult issues on
>    principle to an independent organisation such as OCERT.
> 
> Best Regards
> Lars
> P.S.: I just wanted to make clear that these are my personal views and reflect
> in no way any position of Xen.org or my employer.

Thanks for raising the discussion up a level, Lars. I think we should
be able to come to a consensus on these broad topics fairly quickly,
then start to address some of the finer details.

Matt

[1] http://www.techzoom.net/papers/weis_security_ecosystem_2009.pdf
[2] http://aws.amazon.com/amazon-linux-ami/
[3] http://oss-security.openwall.org/wiki/mailing-lists/distros

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