[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.