[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

[Xen.org security team <security@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
                                 version 4

        Information leak via side effects of speculative execution

UPDATES IN VERSION 4
====================

Added README for determining which shim to use, as well as
instructions for using "Vixen" (HVM shim) and the required
conversion script

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

Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks.  This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor.  Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead.  Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks.  On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.

More information is available here:
  https://meltdownattack.com/
  https://spectreattack.com/
  
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.)  However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.

IMPACT
======

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes.  For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware.  Consult your
operating system provider for more information.

NOTE ON TIMING
==============

This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.

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

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable.  Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer.  ARM
has information on affected models on the following website:
   https://developer.arm.com/support/security-update

For SP3, only Intel processors are vulnerable.  (The hypervisor cannot
be attacked using SP3 on any ARM processors, even those that are
listed as affected by SP3.)

Furthermore, only 64-bit PV guests can exploit SP3 against Xen.  PVH,
HVM, and 32-bit PV guests cannot exploit SP3.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.

RESOLUTION
==========

There is no available resolution for SP1.  A solution may be available
in the future.

We are working on patches which mitigate SP2 but these are not
currently available.  Given that the vulnerabilities are now public,
these will be developed and published in public, initially via
xen-devel.

For guests with legacy PV kernels which cannot be run in HVM or PVH
mode directly, we have developed two "shim" hypervisors that allow PV
guests to run in HVM mode or PVH mode.  The HVM shim (codenamed
"Vixen") is available now.  We expect to have the PVH shim (codenamed
"Comet") available within a few days.  Please read README.which-shim
to determine which shim is suitable for you.

$ sha256sum xsa254*/*
2df6b811ec7a377a9cc717f7a8ed497f3a90928c21cba81182eb4a802e32ecd7  
xsa254/README.vixen
bc04385fd3ec899e1b8c1c001b6169587a8a8b20d5d0d584ff749b7ed67d7e70  
xsa254/README.which-shim
36e825118fa8fca30158e50607580ddf64f6c62e5c5127d87d0042fbe2ff37b2  
xsa254/pvshim-converter.pl
$


NOTE ON LACK OF EMBARGO
=======================

The timetable and process were set by the discloser.

After the intensive initial response period for these vulnerabilities
is over, we will prepare and publish a full timeline, as we have done
in a handful of other cases of significant public interest where we
saw opportunities for process improvement.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJaV8ReAAoJEIP+FMlX6CvZWoUH/joZJ3sMPCs5EHlDcKMcoWXx
YMsZuypqVyotc9WbvBdh3QfdfCEOqouJatHUBkl3Me8bzkJY1IEzcE4BlG0Ku1Bv
s2DKEcUDbEtA7zuJuQukeuYdx4QaqfVr93fnW48P2Ax2X7kBl1cvr5isxjBaPqC2
dHVMqXgwPGPwOzPW7GZjmzDikyPAHgsNxdH/rXdAHSJ8hLVUeQv3zhMaoUmvQiNb
xq7+mSIoVAZr82fXKGKApX2XTxmwq7SgyzAVVfGySID9GGjnGGoSpirpMtkD+7io
rpe0W+KD/muukgzvRd5+eHbx+dIq5MN0VnQiFbc2WmM8HNoJF/R8k/kvLtQfiZ4=
=2xGF
-----END PGP SIGNATURE-----

Attachment: xsa254/README.vixen
Description: Binary data

Attachment: xsa254/README.which-shim
Description: Binary data

Attachment: xsa254/pvshim-converter.pl
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel