Xen Security Advisory 278 v1 - x86: Nested VT-x usable even when disabled

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Xen Security Advisory 278 v1 - x86: Nested VT-x usable even when disabled

Xen.org security team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

                    Xen Security Advisory XSA-278

               x86: Nested VT-x usable even when disabled

ISSUE DESCRIPTION
=================

When running HVM guests, virtual extensions are enabled in hardware because
Xen is using them.  As a result, a guest can blindly execute the
virtualisation instructions, and will exit to Xen for processing.

In the case that the guest hasn't followed the correct (virtual) configuration
procedure, it shouldn't be able to use the instructions, and Xen should
respond with #UD exception.  When nested virtualisation is disabled for the
guest, it is not permitted to complete the configuration procedure.

Unfortunately, when nested virtualisation is intended to be disabled for the
guest, an incorrect default value leads Xen to believe that the configuration
procedure has already been completed.

IMPACT
======

Guest software which blindly plays with the VT-x instructions can cause Xen to
operate on uninitialised data.  As the backing memory is zeroed, this causes
Xen to suffer a NULL pointer dereference, causing a host Denial of Service.

Other behaviours such as memory corruption or privilege escalation have not
been ruled out.

VULNERABLE SYSTEMS
==================

Systems running Xen 4.9 or later are vulnerable.  Systems running Xen 4.8 or
earlier are not vulnerable.

Only Intel x86 systems are vulnerable.  Systems from other x86 vendors, and
other hardware vendors are not vulnerable.

Only x86 HVM and PVH guests can leverage this vulnerability.  x86 PV guests
cannot leverage this vulnerability.

MITIGATION
==========

Running only x86 PV guests will avoid the issue.

For x86 HVM guests, while enabling nested virtualisation for affected guests
does work around this particular DoS, it is not a security supported
configuration and has other know DoS and suspected privilege escalation
vulnerabilities.  Therefore, it is not a mitigation.

CREDITS
=======

This issue was discovered by Sergey Dyasli of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa278.patch           xen-unstable
xsa278-4.11.patch      Xen 4.11, 4.10, 4.9

$ sha256sum xsa278*
d94c59ee170f96af14f0cf696221ba8b9447b86820fe99fba1815ab93cc89cd7  xsa278.patch
22686a9bbfbd38bb74292a28a452012d263875c9064815d4afd3fd6c62df0c3a  xsa278-4.11.patch
$

NOTE CONCERNING LACK OF EMBARGO
===============================

This issue was first reported in private and was in the usual XSA process.

It was later independently reported in public with enough detail for the issue
to be considered fully public.
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlvQ4AQMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZMncIAKPKEhtKfaVxNp3WxA2UYRYQCLjrPieFwn8WF/Bx
Fcou5sCUhKZuRQccM5sOyDT8q/GRwYcvkcn3yXqXCKkijhsEA4fzsDYrCvQlO7RS
xcRMJSBhovz81PPrlDfGVGB6f2Iq3JePVP9DNxwHhgNQJN0+3kdjzEUtKJx3VczE
8LwIpQYyG4Xn3HBIjVD7R6+UiJLcDrD5sdRh9yOgNFNQQUqERtsAOEFJ2raYs/Cm
hUvb5m3HBJSzcsZqdfTe5ovLwpumNygao43xt+lAA1KvKk148yEjO4E1dIklmFOE
1d6Za6n9VD/+vTAo2JMDr0WpHZjzvBxNHkOg4levkYvKiCg=
=fPmO
-----END PGP SIGNATURE-----

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users

xsa278.patch (14K) Download Attachment
xsa278-4.11.patch (14K) Download Attachment