Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-10-09 at 12:24 +0100, George Dunlap wrote:
> On Thu, Oct 9, 2014 at 10:37 AM, Ian Jackson
> <ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 
> > process post-mortem"):
> >> On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> 
> >> wrote:
> >> > My view is that the policy should be clarified to permit deployment
> >> > during embargo.  I see no practical reason for preventing it.
> >>
> >> I agree. If we didnât allow deployment during an embargo a lot more
> >> users would be at risk.
> >>
> >> However, in this context we do need to look at a number of questions:
> >>
> >> a) Risk of someone reverse engineering the vulnerability during
> >> deployment.
> >
> > This is what my caveat is intended to address.
> 
> That's not how I understood your caveat (assuming you mean
> "...PROVIDED THAT any action taken by the service provider gives no
> indication (to their users or anyone else) as to the nature of the
> vulnerability.")
> 
> Just to be clear what I'm talking about (and what I think Lars is
> talking about): Say that there was a fix that was expected to have
> noticeable effects on existing functionality -- for example, breaking
> certain (obscure but occasionally used) configurations, or having a
> measurable performance impact on certain not-uncommon workloads.  This
> might clue the attacker in to what code to audit to try to find the
> vulnerability.

I was wondering about this sort of thing too.

We don't want to leave this up to individual list members, otherwise we
are back in the situation where two members reach different conclusions
and one of them ends up feeling aggrieved. Plus I don't think we can
expect all list members to have the technical understanding to make that
call in the first place.

Ian.
> 
> For one, your caveat is pretty ambiguous: many people took Amazon's
> rebooting to mean that it was a really serious vulnerability (i.e.,
> privilege escalation).  In this case that turned out to be wrong, but
> what it if *had* been for a bug like XSA-7?  Would that constitute
> "giving indication as to the nature of the vulnerability"?
> 
> For two, I would have interpreted this about other actions surrounding
> the deployment, not actually the deployment itself.
> 
> I think that the security team should attempt to determine whether
> pre-disclosure deployment might give away too much information, and
> specifically say in each advisory whether early deployment is allowed
> or not, potentially with specifications about what kind of deployments
> will be allowed (if necessary).  Most of the time this will just be,
> "Rebooting servers to deploy this fix is allowed", but it leaves the
> option open to change it if necessary.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



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