[prev in list] [next in list] [prev in thread] [next in thread]
List: xen-announce
Subject: [Xen-announce] Xen Security Advisory 239 (CVE-2017-15589) - hypervisor stack leak in x86 I/O interce
From: Xen.org security team <security () xen ! org>
Date: 2017-10-18 12:08:27
Message-ID: E1e4n99-0001G3-P0 () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2017-15589 / XSA-239
version 3
hypervisor stack leak in x86 I/O intercept code
UPDATES IN VERSION 3
====================
CVE assigned.
ISSUE DESCRIPTION
=================
Intercepted I/O operations may deal with less than a full machine
word's worth of data. While read paths had been the subject of earlier
XSAs (and hence have been fixed), at least one write path was found
where the data stored into an internal structure could contain bits
from an uninitialized hypervisor stack slot. A subsequent emulated
read would then be able to retrieve these bits.
IMPACT
======
A malicious unprivileged x86 HVM guest may be able to obtain sensitive
information from the host or other guests.
VULNERABLE SYSTEMS
==================
All Xen versions are vulnerable.
Only x86 systems are affected. ARM systems are not affected.
Only HVM guests can leverage this vulnerability. PV guests cannot
leverage this vulnerability.
MITIGATION
==========
Running only PV guests will avoid this issue.
CREDITS
=======
This issue was discovered by Roger Pau Monné of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa239.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x
xsa239-4.5.patch Xen 4.5.x
$ sha256sum xsa239*
eb7971be89199eb3ff510f4f5650fd5a8ec588b9fcb8f89230216fac4214ef21 xsa239.meta
087a8b3cf7ecbdbde593033c127cbcf6c37f532bf33d90f72c19e493970a799c xsa239.patch
b91a68fe67240f2a5bb9460c5b650e9595364afa180f8702aef783815e3d7dcd xsa239-4.5.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJZ50QiAAoJEIP+FMlX6CvZ9+EH/3FDnPzVeA+Rd8rblNpLh7VQ
oyQ0B0olLYPZHLHQ2yzNJAg/1wv1ar7K2Rs0E1kovSqFZWdrTeo0DFKy418+rD6j
TvSxYq0ktC0ir5cUSeExhHRDkBGDlEAuugdC381e0g89KT7Sv+kQz8t06yBV9KIP
hnWPWcGvzeIKQX//Gd5i4618zhqGHI29LBuFJyMdrDcHSdD8f5B81n+pWojZ8JDP
gYbhLHr0MLev2CH0URiegc7FIvbEPbW4rAzuEAKbMLfLMMwPg+eLJsM25WCTWuE7
AiQUvx3zyD76EZ7gjVIDV/AazOWmMpZHrS1Rd+LwNYTeuV77JDebSI6KJ+X0jHc=
=v3zp
-----END PGP SIGNATURE-----
["xsa239.meta" (application/octet-stream)]
["xsa239.patch" (application/octet-stream)]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86/HVM: prefill partially used variable on emulation paths
Certain handlers ignore the access size (vioapic_write() being the
example this was found with), perhaps leading to subsequent reads
seeing data that wasn't actually written by the guest. For
consistency and extra safety also do this on the read path of
hvm_process_io_intercept(), even if this doesn't directly affect what
guests get to see, as we've supposedly already dealt with read handlers
leaving data completely unitialized.
This is XSA-239.
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -129,7 +129,7 @@ static int hvmemul_do_io(
.count = *reps,
.dir = dir,
.df = df,
- .data = data,
+ .data = data_is_addr ? data : 0,
.data_is_ptr = data_is_addr, /* ioreq_t field name is misleading */
.state = STATE_IOREQ_READY,
};
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -127,6 +127,7 @@ int hvm_process_io_intercept(const struc
addr = (p->type == IOREQ_TYPE_COPY) ?
p->addr + step * i :
p->addr;
+ data = 0;
rc = ops->read(handler, addr, p->size, &data);
if ( rc != X86EMUL_OKAY )
break;
@@ -161,6 +162,7 @@ int hvm_process_io_intercept(const struc
{
if ( p->data_is_ptr )
{
+ data = 0;
switch ( hvm_copy_from_guest_phys(&data, p->data + step * i,
p->size) )
{
["xsa239-4.5.patch" (application/octet-stream)]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86/HVM: prefill partially used variable on emulation paths
Certain handlers ignore the access size (vioapic_write() being the
example this was found with), perhaps leading to subsequent reads
seeing data that wasn't actually written by the guest. For
consistency and extra safety also do this on the read path of
hvm_process_io_intercept(), even if this doesn't directly affect what
guests get to see, as we've supposedly already dealt with read handlers
leaving data completely unitialized.
This is XSA-239.
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -55,6 +55,7 @@ static int hvm_mmio_access(struct vcpu *
{
if ( p->dir == IOREQ_READ )
{
+ data = 0;
if ( vio->mmio_retrying )
{
if ( vio->mmio_large_read_bytes != p->size )
@@ -76,6 +77,7 @@ static int hvm_mmio_access(struct vcpu *
{
for ( i = 0; i < p->count; i++ )
{
+ data = 0;
if ( vio->mmio_retrying )
{
if ( vio->mmio_large_read_bytes != p->size )
@@ -124,6 +126,7 @@ static int hvm_mmio_access(struct vcpu *
{
for ( i = 0; i < p->count; i++ )
{
+ data = 0;
switch ( hvm_copy_from_guest_phys(&data, p->data + step * i,
p->size) )
{
@@ -222,6 +225,7 @@ static int process_portio_intercept(port
{
if ( p->dir == IOREQ_READ )
{
+ data = 0;
if ( vio->mmio_retrying )
{
if ( vio->mmio_large_read_bytes != p->size )
@@ -246,6 +250,7 @@ static int process_portio_intercept(port
{
for ( i = 0; i < p->count; i++ )
{
+ data = 0;
if ( vio->mmio_retrying )
{
if ( vio->mmio_large_read_bytes != p->size )
[Attachment #6 (text/plain)]
_______________________________________________
Xen-announce mailing list
Xen-announce@lists.xen.org
https://lists.xen.org/xen-announce
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic