Date: 18 March 2016
Click here for printable version
Click here for PGP verifiable version
-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
Xen Security Advisory CVE-2016-3157 / XSA-171
18 March 2016
AusCERT Security Bulletin Summary
Operating System: Xen
Impact/Access: Increased Privileges -- Existing Account
Denial of Service -- Existing Account
Access Confidential Data -- Existing Account
CVE Names: CVE-2016-3157
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2016-3157 / XSA-171
I/O port access privilege escalation in x86-64 Linux
UPDATES IN VERSION 4
Clarify Vulnerable Systems section.
IRET and POPF do not modify EFLAGS.IOPL when executed by code at a
privilege level other than zero. Since PV Xen guests run at privilege
level 3 (for 64-bit ones; 32-bit ones run at privilege level 1), to
compensate for this the context switching of EFLAGS.IOPL requires the
guest to make use of a dedicated hypercall (PHYSDEVOP_set_iopl). The
invocation of this hypercall, while present in the 32-bit context
switch path, is missing from its 64-bit counterpart.
User mode processes not supposed to be able to access I/O ports may
be granted such permission, potentially resulting in one or more of
in-guest privilege escalation, guest crashes (Denial of Service), or
in-guest information leaks.
All upstream x86-64 Linux versions operating as PV Xen guests are
ARM systems are not vulnerable. x86 HVM guests are not vulnerable.
32-bit Linux guests are not vulnerable.
x86-64 Linux versions derived from linux-2.6.18-xen.hg (XenoLinux) are
We believe that non-Linux guests are not vulnerable, as we are not
aware of any with an analogous bug.
Running only HVM or 32-bit PV guests will avoid this issue.
This issue was discovered by Andy Lutomirski.
Applying the attached patch resolves this issue for the indicated Linux
xsa171.patch Linux 4.5-rc7, Linux 4.4.x
$ sha256sum xsa171*
DEPLOYMENT DURING EMBARGO
The patch is a change to the domU, ie, to the guest, not to hosts.
Where the guest kernel is provided by the host administrator
- - ------------------------------------------------------------
Deployment of the patch by the host administrator is NOT permitted
(except where all the affected systems and VMs are administered and
used 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 a the cloud guest administrator is almost certainly in
a position to see the changes that are made by to the kernel even if
the kernel is provided by the host administrator.
Deployment is permitted only AFTER the embargo ends.
Where the guest kernel is provided by the guest administrator
- - -------------------------------------------------------------
Deployment of the patch (or another which is substantially similar) by
the guest administrator is permitted during the embargo ONLY if
(i) the host administrator organisation is also a member of the Xen
Project Security Issues Predisclosure List.
(ii) all the guest's users are also members of predisclosure list.
(guest users includes administrators of Linux containers running
within the guest).
Restriction (i) is because the host administrator can see changes that
made to the kernel by a guest administrator. Restriction (ii) is
because it is difficult to fully conceal the Linux kernel from
unprivileged guest user processes.
If the host is not operated by a member of the predisclosure list, or
the guest has users outside the predisclousre list, deployment is
permitted only AFTER the embargo ends.
In any case
- - -----------
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, or whose situation is not clearly covered
above, 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:
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to email@example.com
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: firstname.lastname@example.org
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----