[Xen-devel] Livepatching and Xen Security

[George Dunlap <george.dunlap@xxxxxxxxxx>]

# Executive summary

* It is important for the Livepatching feature to be declared
"security supported".

* At the moment it's not clear whether we can get osstest support in
by the release or not, or if we did whether that would be considered
sufficient to consider it supported

* I would argue that if various vendors can demonstrate that they have
tested the key functionality of the feature in one of the 4.9 RCs at
least as well as osstest would to, that should be sufficient to
declare it security supported for 4.9.

# Why is this important?

Having a feature "security supported" does two things.

First of all, it indicates to users which parts of Xen are considered
safe to use in environments where security is important.

One of the key selling points of Xen is its security compared to other
hypervisors.  But there is a lot of functionality which *can* be
enabled in Xen that isn't really secure: for instance, there are
hundreds of devices emulated by qemu that you *can* enable, but for
which it would not be really safe in the face of a determined
attacker.  Statements of security support help indicate to users which
subset of functionality they should use.

Secondly, it indicates whether a bug discovered in the feature will go
through the XenProject Security Response Process -- i.e., whether it
will be issued an XSA.

Issuing an XSA does two things.  First, it allows people on the
predisclosure list to update their systems before issues are made
known to the entire world.  Secondly, it gives people *not* on the
predisclosure list a structured way of finding out about important
security issues about which they may need to take some action.

# Potential Livepatch security issues

To think about what "security support for Livepatching" means, we have
to have to answer the question, "If there were a security-related bug
in Livepatching, what would it look like?"  This helps us think about
what kind of promises we would give, and what kinds of testing we
would consider necessary to provide security support.

In each case, we must ask: Is this the kind of bug that software
vendors and cloud providers would want embargoed notice for?  Is this
the kind of bug that members not on the pre-disclosure list would like
to be notified of so they can react to quickly?

There are four general areas I think there may be bugs.

## Unprivileged access to Livepatching hypercalls

First, and most obvious, would be a bug that allowed unprivileged
guests access to the livepatching hypercalls.  Livepatching's explicit
purpose is to make it as easy as possible to execute arbitrary code
inside the hypervisor, so any bug which gave an unprivileged guest
access would obviously be a major security issue.

## Bugs in the patch creation tools which create patches with vulnerabilities

Suppose that we have hypervisor version A, which has a security
vulnerability, and a software patch which generates hypervisor version
B, which, when built and booted as a normal binary will not have the
vulnerability.

The livepatch creation tools are designed to help developers create a
binary blob, such that when uploaded into a running copy of hypervisor
A, will cause it to behave like hypervisor B.

But suppose there was a bug in the tools, such that the blob would
successfully upload, but leave open vulnerabilities -- either by not
correctly fixing the original vulnerability, or by opening yet a
different vulnerability.

## Bugs in the patch-application code such that vulnerabilities exist
after application

Suppose instead that we have a binary patch which is correct -- i.e.,
if it were applied as designed it would close the vulnerability and
not open a new one.  But suppose that there was a bug in the patch
application code such that, after the patch process reported success,
known vulnerabilities existed.

As a simple example, suppose that the patch was simply not applied,
but that it was reported as applied anyway.

Or suppose that the patch was applied partially, but not completely.
For instance, say there was an off-by-one error that caused only 2 of
3 required functions to be patched.

Or again, suppose there was a bug in the patch application code such
that, as a side effect of applying the patch and closing the original
vulnerability, a secondary vulnerability was opened up -- say, an
accidental modification to a hypercall table or IDT entries.

## Bugs which allow a guest to prevent the application of a livepatch

In order to apply a patch, the livepatching code first makes several
checks, then pauses the entire system while it finishes the change.
To pause the system, it sends a message to all the other processors
telling them to stop what they're doing, and it waits for them to say
they're ready.

You could imagine a bug in either of these two which might be
triggerably by the guest.  For instance, there could be a bug in the
code which checks whether the livepatch can be applied, such that the
guest can make the check fail.  Or, there could be some activity the
guest could do which could repeatedly block the livepatch from being
applied.

## Discussion

I think in all of the above cases, the answer is "yes".

We definitely want to issue an XSA if an unprivileged guest can access
the livepatch hypercalls.

In the case of a bug in the patch generation tools, the risk here
would be that a livepatches had already been 1) created by a
downstream user, or 2) issued by a vendor, such that (if the livepatch
tools bug became public) there would be a knnown vulnerability that
the attacker could exploit.

At the moment generating a live patch is still a very human-intensive
process; there's an argument to be made that humans should be
inspecting the results of the tools anyway and verifying that they
don't do anything bad.

Still, in general we want to help humans as much as possible.  If such
a bug were found, we would want to alert everyone to the *possibility*
that their own patches might contain such a bug, so that they could
double-check to make sure they were OK.  So I think we'd want to issue
an XSA for this one as well.

I think the same goes for bugs in the patch application: If it became
known publicly that under certain conditions, previous patches weren't
being applied, it would raise the risk for our users.  Having a way to
notify particularly vulnerable ones (such as cloud providers)
beforehand, and notify people not on the pre-disclosure list in a
structured way afterwards, would significantly increase the security.

# Testing status and requirements

I'm told we already test that unprivileged guests cannot access the
Livepatch hypercalls in osstest; if so, that aspect should should be
covered.

All that's needed would be for vendors to describe what kinds of
testing they have done for Livepatching.  I think there are two
factors which come into play:

1. Having tested live-patching thoroughly for at least some version of
the codebase

2. Having tested live-patching for one of the Xen 4.9 RCs.

Thoughts?

 -George Dunlap

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