Information

AdvisoryXSA-84
Public release 2014-02-06 12:00
Updated 2023-12-15 15:35
Version 4
CVE(s) CVE-2014-1891 CVE-2014-1892 CVE-2014-1893 CVE-2014-1894
Title integer overflow in several XSM/Flask hypercalls

Files

advisory-84.txt (signed advisory file)
xsa84-4.1.patch
xsa84-4.2.patch
xsa84-unstable-4.3.patch

Advisory


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

 Xen Security Advisory CVE-2014-1891,CVE-2014-1892,CVE-2014-1893,CVE-2014-1894 / XSA-84
                                        version 4

           integer overflow in several XSM/Flask hypercalls

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

Normalize version tags

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

The FLASK_{GET,SET}BOOL, FLASK_USER and FLASK_CONTEXT_TO_SID
suboperations of the flask hypercall are vulnerable to an integer
overflow on the input size. The hypercalls attempt to allocate a
buffer which is 1 larger than this size and is therefore vulnerable to
integer overflow and an attempt to allocate then access a zero byte
buffer.  (CVE-2014-1891)

Xen 3.3 through 4.1, while not affected by the above overflow, have a
different overflow issue on FLASK_{GET,SET}BOOL (CVE-2014-1893) and
expose unreasonably large memory allocation to aribitrary guests
(CVE-2014-1892).

Xen 3.2 (and presumably earlier) exhibit both problems with the
overflow issue being present for more than just the suboperations
listed above.  (CVE-2014-1894 for the subops not covered above.)

The FLASK_GETBOOL op is available to all domains.

The FLASK_SETBOOL op is only available to domains which are granted
access via the Flask policy.  However the permissions check is
performed only after running the vulnerable code and the vulnerability
via this subop is exposed to all domains.

The FLASK_USER and FLASK_CONTEXT_TO_SID ops are only available to
domains which are granted access via the Flask policy.

IMPACT
======

Attempting to access the result of a zero byte allocation results in
a processor fault leading to a denial of service.

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

All Xen versions back to at least 3.2 are vulnerable to this issue when
built with XSM/Flask support. XSM support is disabled by default and is
enabled by building with XSM_ENABLE=y.

We have not checked earlier versions of Xen, but it is likely that
they are vulnerable to this or related vulnerabilities.

All Xen versions built with XSM_ENABLE=y are vulnerable.

MITIGATION
==========

There is no useful mitigation available in installations where XSM
support is actually in use.

In other systems, compiling it out (with XSM_ENABLE=n) will avoid the
vulnerability.

CREDITS
=======

This issue was discovered by Matthew Daley.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa84-unstable-4.3.patch        xen-unstable, Xen 4.3.x
xsa84-4.2.patch                 Xen 4.2.x
xsa84-4.1.patch                 Xen 4.1.x


$ sha256sum xsa84*.patch
e33dd94499959363ad01bebefda9733683c49fd42a9641cf2d7edcd87f853d55  xsa84-4.1.patch
433f3c8a202482c51a48dc0e9e47ac8751d1c0d0759b7bcd22804e1856279a89  xsa84-4.2.patch
64ae433eb606c5446184c08e6fceb9f660ed9a9c28ec112c8cc529251b3b49fb  xsa84-unstable-4.3.patch
$
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b+oMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfwgIAM0mibdaMOQgu2H9QNwS+alcBdZ1tamW1L0itGP7
Uwji4CHk6rZ09ceEUd+ouvlMj1kB5VEmyTLmo2jyRUMcWY02EAfeIhxS1deoGbor
ifRgGRh1gJoN7WTmPp9XuX5TbtRE+4VqiLVmxsH50SNgkEFwgCx+z90sUGdNT5d9
sev8wV52nm+jaYEU+Es37WiH2XnBxD6xjHGLhUDluNWUDJkvBdaf84hUW53tcs43
JV8j4+sXAUJUoPLcMwkfFXJwjNvDX6if1e50q7tJ4v+JjRNAiBHiKqDQh9xuojks
lurblxZEMCfpq3aIu3IkWQ5BKOuvkaVpdA/1OktbyFUdvzI=
=QjjG
-----END PGP SIGNATURE-----


Xenproject.org Security Team