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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
Representing only personal (i.e. not necessarily my employer's)
opinions below.

> 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.
> 
> In particular, if the process explained its purpose, we would be able
> to refer to the spirit of the document when making interpretation
> decisions or dealing with issues not clearly resolved by the document.
> 
> In this context we need to decide whether:
>  (a) the predisclosure arrangements are just there so that
>      organisations can backport patches, develop and test updated
>      versions, and so forth;
>  (b) the arrangements are also intended to allow operators to deploy
>      fixed versions.
> 
> 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.

(a). Anything beyond may give (and apparently gave in the case
at hand) unfair advantages to certain downstreams over others.

> 2. Extension of embargo dates
> 
> The most controversial decision was whether the embargo date might be
> extended after it had originally been set.  We resisted these
> suggestions, referring to the process document, which does not
> contemplate extending the disclosure period.  However, when a
> predisclosure list member pressured the discoverer into requesting an
> extension, we felt the best interpretation of the process document
> required us to acquiesce.
> 
> Specifically, of course, we as a team would like clearer guidance from
> the process about whether, and if so under what circumstances, a
> predisclosure period should be extended.

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. He might provide an
initial suggestion, but we ought to set a period of time (say, a
week or less) during which adjustment proposals can be made.

Extensions to the embargo period should be limited exclusively to
cases where problems addressing the problem in a timely manner
(including eventual later _necessary_ adjustments to the fixes)
arise.

> 3. Decisionmaking
> 
> It was suggested to us several times, and indeed seemed to be regarded
> by some as an underlying principle, that the predisclosure list
> members should be making the decisions about disclosure schedule etc.
> 
> The question of who is to make the decisions, and on what basis, needs
> to be addressed.

See above. Leaving this to the discretion of the discoverer is
neither open nor fair.

> 4. Length of (default) predisclosure period
> 
> Several members of the predisclosure list suggested that the
> predisclosure period was too short.  Others were ready within the
> predisclosure period's timeframe, and were disappointed to see it
> extended and to have to delay their fixes.

Setting a default period might be counter productive. There may
be cases (for example had we wanted to fix XSA-9 properly)
where developing a fix could take quite a bit of time. Not having
a fix ready shouldn't, however, prevent initial announcements of
a problem.

> 5. Criteria for predisclosure list membership
> 
> We had one request from a public Xen cloud provider to be provided
> with predisclosure information.  However it appeared to us that they
> didn't meet the size threshold in the process document.
> 
> The size threshold is of course open to discussion.
> 
> We need to clarify whether upstreams and hardware vendors should be on
> the predisclosure list.  Currently we have one notable upstream vendor
> on that list.
> 
> Our preliminary view is that the predisclosure list should be used for
> downstream notifications.  Upstreams, including hardware
> manufacturers, should be brought in to the disclosure process as
> needed.  And as noted, our process for making sure we do that properly
> needs to be formalised.
> 
> It is probably time for a review of the membership of the
> predisclosure list, in any case, after we have incorporated any
> changes to the criteria which are agreed as a result of this
> discussion.

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

As to downstreams, I think only direct ones should be involved in
any decision making processes. Indirect ones might be allowed on
the list, but exclusively as observers. Mis-use of the observer role
(e.g. as in influencing those participating in decision making in
undue ways), should it become known, should result in removal of
list membership.

> 6. Sharing of information and code between predisclosure participants
> 
> We need the process document to be clearer about what kinds of
> communications are contemplated _between_ members of the predisclosure
> list.
> 
> One particular issue here which also relates to the predisclosure
> membership criteria, is whether large indirect consumers of Xen should
> be on the predisclosure list in their own right.  That would allow
> them to deploy the fix before the embargo date.  It would also allow
> them to prepare for testing and deployment, before the fix is
> available from their vendor (who would in this scenario also be
> entitled to be a predisclosure list member).
> 
> In this context, the process needs to clarify whether vendors may
> release fixed binaries during the predisclosure period.  Certainly
> these should not be released other than to predisclosure list members,
> since the nature of a bug can often by discovered by reverse
> engineering.  But can they be released to predisclousre list members ?

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.

> 7. Public communications during the embargo period
> 
> We need to clarify what individual vendors are allowed to say during
> the embargo period.  It was brought to our attention that one public
> cloud provider told its users that their VMs would be migrated due to
> "a vendor issue" which would be revealed in "a few weeks".  Our view
> was that that was fine.
> 
> As a starting point, it seems to us that it is OK to disclose that
> there is an issue, including its XSA and CVE numbers and its planned
> disclosure date; but that it is not OK to disclose the impact, scope,
> set of vulnerable systems, and certainly not the nature of the
> vulnerability.
> 
> And we need to clarify what information the security team should give
> out when we get an enquiry from a community member about an embargoed
> problem.

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

The alternative would be to not do and allow any communication,
which I think is not realistic to enforce.

> 8. Predisclosure subscription process, and email address criteria
> 
> We certainly need to clarify the subscription process to the list, to
> make it clear that the organisation's security team should request all
> subscriptions and that self-subscriptions via the mailing list
> interface will be rejected out of hand.  The current arrangements have
> caused quite a lot of admin work, to confirm various change requests.
> 
> The predisclosure list contains a number of individuals at various
> organisations.  One vendor seemed to get into difficulty because it
> had only one individual on the predisclosure list, which seems to have
> unfortunately kept their established team in the dark during the early
> stages of the process.  The process document requires that downstreams
> on the list have established security teams.  Should we require that
> such response teams' contact details be publicly advertised ?  Should
> we insist that only response teams' role addresses may be included on
> the list ?

Yes.

> 9. Vulnerability process scope
> 
> We need to clarify the scope of the process document.  Currently it
> looks like it covers every Xen.org project.
> 
> While it would be a nice ideal to support every Xen.org project this
> way, in practice the team behind security@xen do not have the
> expertise or resources to fix problems in (say) XCP, or the ARM PV
> port.  Our capability is concentrated on the "Upstream Xen" codebase
> (xen-*.hg and its sub-repositories) and the Xen support code in Linux.
> 
> Perhaps this could be dealt with by making it clear that problems are
> handled on a best effort basis.

Agreed.

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

> 11. Transparency
> 
> We think the process document should explicitly state that any
> potentially controversial private decisions made by the Xen.org
> security response team should be disclosed after the vulnerability
> itself is disclosed.

While fine from a theoretical pov, this places extra work on the
security response team, and I'm therefore not sure it's worth it.

Perhaps, if anything, such information (when regarding details of
the implementation of a fix) could go into the commit message.

> 13. Patch development and review
> 
> The patch development process is too closed and not robust enough.
> 
> We need to be much clearer both about the need for security patches to
> fix things in the smallest, simplest and most reliable way, and not
> fix or "improve" matters in unrelated ways.  Our internal code review
> needs to be much better.

I think this shouldn't be as strict. Selecting e.g. between larger,
less performance intrusive changes over smaller changes with a
larger impact on performance should be done on a case by case
basis. (I'm still of the opinion that the original XSA-7 fix, which
now became c/s 25485:5b6a857411ba [minus the now pointless
adjustment to the hypercall path], would have been the better
one, despite it having required quite a bit of thinking to verify
that it is sufficient in that final form. The main problem here was
that no-one, including me, took the time early on to document all
the affected code paths for others to verify, and patch review
wasn't concise enough either.)

If in doubt, room should be provided to involve individuals not
on the security response team (of course requiring them to not
disclose the knowledge gained).

> We need to clarify that other issues discovered during the course of
> investigating a security disclosure will not be publicly discussed
> without first consulting the Xen.org security team, regardless of
> their actual relationship to the vulnerability at hand or expected
> security impact.  Otherwise there is a substantial risk that such
> changes will draw attention to embargoed problems.

I don't think this is strictly necessary, nor a problem. This has
become a problem in the recent process mainly due to the
extraordinary length of the embargo period.

> It may be that it would be a better idea to send out earlier
> advisories without patches to the predisclosure list, to enable those
> predisclosure list members who would like to do so to help with
> development and testing of the patches.  If so this needs to be
> catered for.

As said earlier, if a fix is available, it of course should be included.
But there shouldn't be any requirement for that.

> 14. Early consideration of which other organisations to bring in
> 
> Our process needs to have, very early on, an explicit step to of
> deciding which other projects/organisations may also be vulnerable and
> may therefore need to be part of the same disclosure process.  It also
> needs to make sure that we ask for any help (for example from
> upstreams or hardware vendors) as soon as possible.

Our security response team should only take our projects into
consideration. Cross project vulnerabilities should be managed
by entities set up to deal with this. (Not that I'm generally in
favor of copying bad behavior, but note how the problem in
XSA-7 was not brought to our or other OS vendors' attention
when dealt with years ago in Linux.)

Jan

> We also need to explicitly determine the availability of various key
> players over the disclosure timeline as an early step.  One of the
> difficulties we encountered was that one of the more important team
> members was unexpectedly out of their office at a critical point.
> 
> 
> 15. Process automation
> 
> Many of the advisory versions sent to the predisclosure list contained
> clerical errors.  Our processes for constructing these need to be
> made more automatic.


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