Xen project Mailing List

[Xen-devel] Xen Security Advisory 247 - Missing p2m error checking in PoD code

To: xen-announce@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxx, oss-security@xxxxxxxxxxxxxxxxxx

From: Xen.org security team <security@xxxxxxx>

Date: Tue, 28 Nov 2017 12:00:24 +0000

Cc: "Xen.org security team" <security-team-members@xxxxxxx>

Delivery-date: Tue, 28 Nov 2017 12:00:40 +0000

List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory XSA-247 version 2 Missing p2m error checking in PoD code UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Certain actions require modification of entries in a guest's P2M (Physical-to-Machine) table. When large pages are in use for this table, such an operation may incur a memory allocation (to replace a large mapping with individual smaller ones). If this allocation fails, the p2m_set_entry() function will return an error. Unfortunately, several places in the populate-on-demand code don't check the return value of p2m_set_entry() to see if it succeeded. In some cases, the operation was meant to remove an entry from the p2m table. If this removal fails, a malicious guest may engineer that the page be returned to the Xen free list, making it available to be allocated to another domain, while it retains a writable mapping to the page. In other cases, the operation was meant to remove special populate-on-demand entries; if this removal fails, the internal accounting becomes inconsistent and may eventually hit a BUG(). The allocation involved comes from a separate pool of memory created when the domain is created; under normal operating conditions it never fails, but a malicious guest may be able to engineer situations where this pool is exhausted. IMPACT ====== An unprivileged guest can retain a writable mapping of freed memory. Depending on how this page is used, it could result in either an information leak, or full privilege escalation. Alternatively, an unprivileged guest can cause Xen to hit a BUG(), causing a clean crash - ie, host-wide denial-of-service (DoS). VULNERABLE SYSTEMS ================== All systems from Xen 3.4 are vulnerable. Only x86 systems are vulnerable. ARM is not vulnerable. x86 PV VMs cannot leverage the vulnerability. Only systems with 2MiB or 1GiB HAP pages enabled are vulnerable. The vulnerability is largely restricted to HVM guests which have been constructed in Populate-on-Demand mode (i.e. with memory < maxmem): x86 HVM domains without PoD (i.e. started with memory == maxmem, or without mentioning "maxmem" in the guest config file) also cannot leverage the vulnerability, in recent enough Xen versions: 4.8.x and later: all versions safe if PoD not configured 4.7.x: 4.7.1 and later safe if PoD not configured 4.6.x: 4.6.4 and later safe if PoD not configured 4.5.x: 4.5.4 and later safe if PoD not configured 4.4.x and earlier: all versions vulnerable even if PoD not configured The commit required to prevent this vulnerability when PoD not configured is 2a99aa99fc84a45f505f84802af56b006d14c52e xen/physmap: Do not permit a guest to populate PoD pages for itself and the corresponding backports. MITIGATION ========== Running only PV guests will avoid this issue. Running HVM guests only in non-PoD mode (maxmem == memory) will also avoid this issue. NOTE: In older releases of Xen, an HVM guest can create PoD entries itself; so this mitigation will not be effective. Specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will also avoid the vulnerability. Alternatively, running all x86 HVM guests in shadow mode will also avoid this vulnerability. (For example, by specifying "hap=0" in the xl domain configuration file.) CREDITS ======= This issue was discovered by George Dunlap of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa247/*.patch xen-unstable xsa247-4.9/*.patch Xen 4.9.x xsa247-4.8/*.patch Xen 4.8.x xsa247-4.7/*.patch Xen 4.7.x xsa247-4.6/*.patch Xen 4.6.x xsa247-4.5/*.patch Xen 4.5.x $ sha256sum xsa247* xsa247*/* e8fc454c35f429ab60b94c0e812f86fd2b3b37edfff2bfdcc13a7e13ebc2efbe xsa247.meta 59e977d81ad85c25572b79db48d62b4f040026e88f51fe61051b7d30e97fad06 xsa247-4.5/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 6221f5fc7899253888a1711e83436f1b8ddc51046ec920d83b7ea2f4266d13f7 xsa247-4.5/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch f54c4984731f9138e522685e98359a0bb409146091fedb8b7beaac48b3460c22 xsa247-4.6/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 258aaa76e164d70fbfead9de1370577c328dff78c09b81ac7b708fd5c530859a xsa247-4.6/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 85f0d5f3940bb27f84867b9ac227636a786519dfc1b35ad82f402f9c044ecac9 xsa247-4.7/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 8f0d45b617e0b4c0c1ff490e84c6415f1444696d2afce09eeaa970fbedb8f4c3 xsa247-4.7/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 580771a125aa577ff4c7607679ef5d8d6c668446f4573bf11e4fe6829d02d157 xsa247-4.8/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch f88d252305d8229374f3fe25bae3c9ea165acab28be9908a1a9a816ae85170ac xsa247-4.8/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 5fe123448b8ea63f96495462a274d986016264acef4a81e555848ae0d38bd035 xsa247-4.9/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch f6e061be4c6355a8d949d258bf1180ff607ce95ca40213cc0e2ee112db435ebd xsa247-4.9/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 4cfa8a89f0d2c4a7bf09f31df1e3050b3cce685efd01a17196e991e02d8dd61d xsa247/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 37d7f639af2c857d5232ab69aa9c576c37e6a46a7b246d0cd1cc6d05a93360ba xsa247/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.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, with ONE exception: Removing the ability to boot in populate-on-demand mode is NOT permitted during the embargo on public cloud systems. This is because doing so might alert attackers to the nature of the vulnerability. Deployment of this mitigation is permitted only AFTER the embargo ends. 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 iQEcBAEBCAAGBQJaHU9KAAoJEIP+FMlX6CvZ8jAH/2mwq7lDxVJVMIVXWZg1b3jU eVk+yXKh3x1piFUa5jyjiSzpWW7IDnYL3eYbTKoYbAfvWFmM+VPdr6cyhq35T8pv KVc6Ml+t2gHrBPE6kAsHiKUWTW0pYP/vbfQVRrGx0br7+d0+LVITi8NNc9uRLwqp eJOhTe3h/Cxoy9Du38AlabDBVXOieKHzJOPNoCLCRkhKL1Jyhg8uEBtZyytc/pOx xM88uiZ/NIk+nu28fiFiy1EARzS1hhNfb4t2QsmKxFtw0Kkyq7D025Tg/tpKi/Uh qx2ek6NYMQbIgozyWLlrZOdfxWvFJpIj/5ZhHL/rpawAOfJk3+CwW8OCzfEBKeY= =q8YR -----END PGP SIGNATURE-----

Attachment: xsa247.meta
Description: Binary data

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

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.