[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 133 (CVE-2015-3456) - Privilege escalation via emulated floppy
From: Xen.org security team <security () xen ! org>
Date: 2015-05-13 11:16:02
Message-ID: E1YsUdu-0008EI-DZ () xenbits ! xen ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2015-3456 / XSA-133
version 2
Privilege escalation via emulated floppy disk drive
UPDATES IN VERSION 2
====================
Public release.
ISSUE DESCRIPTION
=================
The code in qemu which emulates a floppy disk controller did not
correctly bounds check accesses to an array and therefore was
vulnerable to a buffer overflow attack.
IMPACT
======
A guest which has access to an emulated floppy device can exploit this
vulnerability to take over the qemu process elevating its privilege to
that of the qemu process.
VULNERABLE SYSTEMS
==================
All Xen systems running x86 HVM guests without stubdomains are
vulnerable to this depending on the specific guest configuration. The
default configuration is vulnerable.
Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.
Guests using a qemu-dm stubdomain to run the device model are only
vulnerable to takeover of that service domain.
Systems running only x86 PV guests are not vulnerable.
ARM systems are not vulnerable.
MITIGATION
==========
Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.
qemu-dm stubdomains are only available with the traditional "qemu-xen"
version.
CREDITS
=======
This issue was discovered by Jason Geffner, Senior Security Researcher
at CrowdStrike.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa133-qemuu.patch qemu-upstream-unstable, Xen 4.5.x, Xen 4.4.x
xsa133-qemuu-4.3-4.2.patch qemu-upstream-unstable, Xen 4.3.x, Xen 4.2.x
xsa133-qemut.patch qemu-xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x
$ sha256sum xsa133*.patch
e7ca0106a9d4bfe472b3b52bbed8646b47305634ff16c3e17ed6185296a7e7ff xsa133-qemut.patch
0cbc0415ef63bc195a0338441f3770d9fe6741e894879e35d1a6609ad028e42f xsa133-qemuu.patch
cf735c1ecb6a40ca57d408e5c01725eca5b9b0a14b1d31b4362dc3f036bdeb28 xsa133-qemuu-4.3-4.2.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches 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: Deployment of the mitigation by enabling stubdomains 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. This is because this configuration change may be
visible to the guest.
Also, 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.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJVUzJdAAoJEIP+FMlX6CvZnJcH/iszFBI+ltmOGxfCtSmnnkdu
6GZUFCVimeVG2ZfDCe1Bvw63ZMeB8AMUr2KmFrg0pOfC7m1Mc/4UhczpqeY9G1i0
kPCcNiK37Ju0otFN1AODHaYGhu6pgfTM+QV1muFVXHf9QibmH+vEy7HEN34Mtv/2
gGRmxLJnkHFME2sISuqhDsxIMf5QWN28I412/QqK8/mJMuvCJHqbLs/fv9f0uj9g
sgAVCb3gsqNS7SSK1v49PqK+lQV+BkPR8pi8ODdL301iZWfu8PbVpYa5A84LVQF0
4ZnlVfWqeKXF7GlsuviinhQIoUIvSktf9tg65fM48Thk0UUp+MyHVkh4GkT/+Eo=
=rN8t
-----END PGP SIGNATURE-----
["xsa133-qemut.patch" (application/octet-stream)]
From ac7ddbe342d7aa2303c39ca731cc6229dbbd739b Mon Sep 17 00:00:00 2001
From: Petr Matousek <pmatouse@redhat.com>
Date: Wed, 6 May 2015 09:48:59 +0200
Subject: [PATCH] fdc: force the fifo access to be in bounds of the allocated buffer
During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.
Fix this by making sure that the index is always bounded by the
allocated memory.
This is CVE-2015-3456.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
---
hw/fdc.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index b00a4ec..aba02e4 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1318,7 +1318,7 @@ static uint32_t fdctrl_read_data (fdctrl_t *fdctrl)
{
fdrive_t *cur_drv;
uint32_t retval = 0;
- int pos;
+ uint32_t pos;
cur_drv = get_cur_drv(fdctrl);
fdctrl->dsr &= ~FD_DSR_PWRDOWN;
@@ -1327,8 +1327,8 @@ static uint32_t fdctrl_read_data (fdctrl_t *fdctrl)
return 0;
}
pos = fdctrl->data_pos;
+ pos %= FD_SECTOR_LEN;
if (fdctrl->msr & FD_MSR_NONDMA) {
- pos %= FD_SECTOR_LEN;
if (pos == 0) {
if (fdctrl->data_pos != 0)
if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
@@ -1673,10 +1673,13 @@ static void fdctrl_handle_option (fdctrl_t *fdctrl, int direction)
static void fdctrl_handle_drive_specification_command (fdctrl_t *fdctrl, int direction)
{
fdrive_t *cur_drv = get_cur_drv(fdctrl);
+ uint32_t pos;
- if (fdctrl->fifo[fdctrl->data_pos - 1] & 0x80) {
+ pos = fdctrl->data_pos - 1;
+ pos %= FD_SECTOR_LEN;
+ if (fdctrl->fifo[pos] & 0x80) {
/* Command parameters done */
- if (fdctrl->fifo[fdctrl->data_pos - 1] & 0x40) {
+ if (fdctrl->fifo[pos] & 0x40) {
fdctrl->fifo[0] = fdctrl->fifo[1];
fdctrl->fifo[2] = 0;
fdctrl->fifo[3] = 0;
@@ -1771,7 +1774,7 @@ static uint8_t command_to_handler[256];
static void fdctrl_write_data (fdctrl_t *fdctrl, uint32_t value)
{
fdrive_t *cur_drv;
- int pos;
+ uint32_t pos;
/* Reset mode */
if (!(fdctrl->dor & FD_DOR_nRESET)) {
@@ -1817,7 +1820,9 @@ static void fdctrl_write_data (fdctrl_t *fdctrl, uint32_t value)
}
FLOPPY_DPRINTF("%s: %02x\n", __func__, value);
- fdctrl->fifo[fdctrl->data_pos++] = value;
+ pos = fdctrl->data_pos++;
+ pos %= FD_SECTOR_LEN;
+ fdctrl->fifo[pos] = value;
if (fdctrl->data_pos == fdctrl->data_len) {
/* We now have all parameters
* and will be able to treat the command
["xsa133-qemuu.patch" (application/octet-stream)]
From ac7ddbe342d7aa2303c39ca731cc6229dbbd739b Mon Sep 17 00:00:00 2001
From: Petr Matousek <pmatouse@redhat.com>
Date: Wed, 6 May 2015 09:48:59 +0200
Subject: [PATCH] fdc: force the fifo access to be in bounds of the allocated buffer
During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.
Fix this by making sure that the index is always bounded by the
allocated memory.
This is CVE-2015-3456.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
---
hw/block/fdc.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index f72a392..d8a8edd 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -1497,7 +1497,7 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
{
FDrive *cur_drv;
uint32_t retval = 0;
- int pos;
+ uint32_t pos;
cur_drv = get_cur_drv(fdctrl);
fdctrl->dsr &= ~FD_DSR_PWRDOWN;
@@ -1506,8 +1506,8 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
return 0;
}
pos = fdctrl->data_pos;
+ pos %= FD_SECTOR_LEN;
if (fdctrl->msr & FD_MSR_NONDMA) {
- pos %= FD_SECTOR_LEN;
if (pos == 0) {
if (fdctrl->data_pos != 0)
if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
@@ -1852,10 +1852,13 @@ static void fdctrl_handle_option(FDCtrl *fdctrl, int direction)
static void fdctrl_handle_drive_specification_command(FDCtrl *fdctrl, int direction)
{
FDrive *cur_drv = get_cur_drv(fdctrl);
+ uint32_t pos;
- if (fdctrl->fifo[fdctrl->data_pos - 1] & 0x80) {
+ pos = fdctrl->data_pos - 1;
+ pos %= FD_SECTOR_LEN;
+ if (fdctrl->fifo[pos] & 0x80) {
/* Command parameters done */
- if (fdctrl->fifo[fdctrl->data_pos - 1] & 0x40) {
+ if (fdctrl->fifo[pos] & 0x40) {
fdctrl->fifo[0] = fdctrl->fifo[1];
fdctrl->fifo[2] = 0;
fdctrl->fifo[3] = 0;
@@ -1955,7 +1958,7 @@ static uint8_t command_to_handler[256];
static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
{
FDrive *cur_drv;
- int pos;
+ uint32_t pos;
/* Reset mode */
if (!(fdctrl->dor & FD_DOR_nRESET)) {
@@ -2004,7 +2007,9 @@ static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
}
FLOPPY_DPRINTF("%s: %02x\n", __func__, value);
- fdctrl->fifo[fdctrl->data_pos++] = value;
+ pos = fdctrl->data_pos++;
+ pos %= FD_SECTOR_LEN;
+ fdctrl->fifo[pos] = value;
if (fdctrl->data_pos == fdctrl->data_len) {
/* We now have all parameters
* and will be able to treat the command
--
2.1.0
["xsa133-qemuu-4.3-4.2.patch" (application/octet-stream)]
From ac7ddbe342d7aa2303c39ca731cc6229dbbd739b Mon Sep 17 00:00:00 2001
From: Petr Matousek <pmatouse@redhat.com>
Date: Wed, 6 May 2015 09:48:59 +0200
Subject: [PATCH] fdc: force the fifo access to be in bounds of the allocated buffer
During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.
Fix this by making sure that the index is always bounded by the
allocated memory.
This is CVE-2015-3456.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
---
hw/fdc.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index f72a392..d8a8edd 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1497,7 +1497,7 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
{
FDrive *cur_drv;
uint32_t retval = 0;
- int pos;
+ uint32_t pos;
cur_drv = get_cur_drv(fdctrl);
fdctrl->dsr &= ~FD_DSR_PWRDOWN;
@@ -1506,8 +1506,8 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
return 0;
}
pos = fdctrl->data_pos;
+ pos %= FD_SECTOR_LEN;
if (fdctrl->msr & FD_MSR_NONDMA) {
- pos %= FD_SECTOR_LEN;
if (pos == 0) {
if (fdctrl->data_pos != 0)
if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
@@ -1852,10 +1852,13 @@ static void fdctrl_handle_option(FDCtrl *fdctrl, int direction)
static void fdctrl_handle_drive_specification_command(FDCtrl *fdctrl, int direction)
{
FDrive *cur_drv = get_cur_drv(fdctrl);
+ uint32_t pos;
- if (fdctrl->fifo[fdctrl->data_pos - 1] & 0x80) {
+ pos = fdctrl->data_pos - 1;
+ pos %= FD_SECTOR_LEN;
+ if (fdctrl->fifo[pos] & 0x80) {
/* Command parameters done */
- if (fdctrl->fifo[fdctrl->data_pos - 1] & 0x40) {
+ if (fdctrl->fifo[pos] & 0x40) {
fdctrl->fifo[0] = fdctrl->fifo[1];
fdctrl->fifo[2] = 0;
fdctrl->fifo[3] = 0;
@@ -1955,7 +1958,7 @@ static uint8_t command_to_handler[256];
static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
{
FDrive *cur_drv;
- int pos;
+ uint32_t pos;
/* Reset mode */
if (!(fdctrl->dor & FD_DOR_nRESET)) {
@@ -2004,7 +2007,9 @@ static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
}
FLOPPY_DPRINTF("%s: %02x\n", __func__, value);
- fdctrl->fifo[fdctrl->data_pos++] = value;
+ pos = fdctrl->data_pos++;
+ pos %= FD_SECTOR_LEN;
+ fdctrl->fifo[pos] = value;
if (fdctrl->data_pos == fdctrl->data_len) {
/* We now have all parameters
* and will be able to treat the command
--
2.1.0
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic