Xen project Mailing List

[Xen-users] Xen Security Advisory 247 (CVE-2017-17045) - 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: Thu, 30 Nov 2017 11:59:53 +0000

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

Delivery-date: Thu, 30 Nov 2017 12:00:53 +0000

List-id: Xen user discussion <xen-users.lists.xenproject.org>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2017-17045 / XSA-247 version 3 Missing p2m error checking in PoD code UPDATES IN VERSION 3 ==================== CVE assigned. Fixed "Reported-by" tags in patch commit messages. 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 3a8c0e02e9c94f68119f21a334ef70c409b71270c7de223d7d9163dbc1cfa286 xsa247-4.5/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 6851ec78da2e91b03c8f3016311d32354a4dacf99ad20ea4f5dc1ed493d42a60 xsa247-4.5/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch dce7e6c1961a85f59d20a3a98ea02d677a4956c3caf5273ea0b890d977cda3e5 xsa247-4.6/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 110de2762531654b77fc38e4f2ee0bae76233e59557c6f6190e839065f9563cc xsa247-4.6/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch d149342e4d40dfb550f8af6d05cd20a34889d64fb33f967fe77cf89b4ea8504a xsa247-4.7/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 3c8a7bfdb408af0224cf6f5471b0fd9dd1a9a1ded7207e427b02268ca2906aa6 xsa247-4.7/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 7ddbd99a30dcddc9a4e0dc7e2f4cfa63abb6237c6d9a706b729cf9df5f34b869 xsa247-4.8/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 4574e27bb76d6dbb357b4dd8efa5fbbbffa69d17ea9c8f8330d3ef19f6cb3fce xsa247-4.8/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 2d0656e84be3b8eb828c199463c5532bddd16cf6e1159ce512a304ef85359422 xsa247-4.9/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch f7429ae9fc9934d3a91aa6f3b9d2dc7a7e464128e4e2a8a71e7c8f26affdb731 xsa247-4.9/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch 024bce64257936048dff6cd66a0ba3212985cad42e78357a1c3513873099ebe2 xsa247/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch 32bb016003d7c37452222cacf22e74b4d29a227d6a808ae89c83293a2bd12f40 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 iQEcBAEBCAAGBQJaH/KPAAoJEIP+FMlX6CvZXrkH/AyVeBsY/MhMmPp7lfV9no52 FHQJF84UDrVDuYeQGVLbTcpXW+3ndEnLrg7Y2N6r6be1qn/KSKLtRO1gh+4mpRg4 n/bBKjldHTsVtr2lb51w6cd0AnibqP+9aSdT5qfselBVpwPBIuDsmny7ZQQnhZuN CwRiKp8uNQ/RNxZHPOZ0k5FmugKQcysj0kSjtNvP+11Fk2b8tJP5o4tMozP/+Umu kv9YAp5WxqqJUHtb25Abf7pszgmp72a19ajvUZK0TPNTajKbQBnBNEoC+GoocFjV eu1iVOxduinIoCjNE/67GXQWajsF6ANnWz+dka306C4BS5WXWOWpMbdaAuLCq7Q= =wtMZ -----END PGP SIGNATURE-----

Attachment: xsa247.meta
Description: Binary data

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

©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.