Hacker News Reader

Comment by lelf | Hacker News Reader

> Deployment of patches or mitigations is NOT permitted (except on systems used and administered only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted.

What is the rationale for this?

View on HN

XEN embargoes patches to make sure they are released as synchronous as possible (i.e. patches hit the major distros and are deployed to all major deployments at the same time). The additional restriction in this case suggests that they think that observing a patched system as customer allows to figure out details of the vulnerability.

> The decision not to permit deployment was made by the group that, at their discretion, disclosed the issue to the Xen Project Security Team.

Xen has, in the past, worked with major cloud service providers to get patches deployed early. Perhaps the view was that the major cloud providers aren't enabling cdrom to begin with, or are using stubdomains, so it wasn't worth risking the broader exposure; or perhaps there were past incidents with early disclosure by cloud providers.

Note that it says "by the group that disclosed the issue". Xen's security process says that it's the people who disclose issues to xen-security that get to make this decision about pre-deployment.

Presumably it's because public deployment would have been noticed by malicious actors, who would have reverse engineered the fix and tried to use the exploit elsewhere.

I'm guessing that the embargo has run out and it's no longer restricted.

Perhaps its possible to pick up on the change from inside the Guest VM, and patching the problem on a public cloud would potentially expose the issue before members of the "Xen project Security Issues Predispose list" had a chance to patch? I'm not sure.

Reply on news.ycombinator.com