Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2019.0695 Multiple vulnerabilities in Xen 6 March 2019 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Product: Xen Publisher: Xen Operating System: Xen Impact/Access: Root Compromise -- Existing Account Increased Privileges -- Existing Account Access Privileged Data -- Existing Account Denial of Service -- Existing Account Resolution: Patch/Upgrade Original Bulletin: http://xenbits.xen.org/xsa/advisory-284.html http://xenbits.xen.org/xsa/advisory-285.html http://xenbits.xen.org/xsa/advisory-290.html Comment: This bulletin contains three (3) Xen security advisories. - --------------------------BEGIN INCLUDED TEXT-------------------- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory XSA-284 version 2 grant table transfer issues on large hosts UPDATES IN VERSION 2 ==================== Metadata updated to remove dependency on XSA-283. Public release. ISSUE DESCRIPTION ================= When the code processing grant table transfer requests finds a page with an address too large to be represented in the interface with the guest, it allocates a replacement page and copies page contents. However, the code doing so fails to set the newly allocated page's accounting properties correctly, resulting in the page becoming not only unusable by the target domain, but also unfreeable upon domain cleanup. The page as well as certain other remnants of an affected guest will be leaked. Furthermore internal state of the processing code was also not updated correctly, resulting in the insertion of an IOMMU mapping to the page being replaced (and subsequently freed), allowing the domain access to memory it does not own. IMPACT ====== The primary impact is a memory leak. Malicious or buggy guests with passed through PCI devices may also be able to escalate their privileges, crash the host, or access data belonging to other guests. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable. 64-bit x86 PV guests can leverage the vulnerability on hosts with physical memory extending past the 16 TiB boundary. This is only possible for hypervisors built with CONFIG_BIGMEM enabled. 32-bit x86 PV guests can leverage the vulnerability on hosts with physical memory extending past the 168 GiB boundary. x86 HVM and PVH guests cannot leverage the vulnerability on libxl based systems. On xend based systems x86 HVM guests can leverage the vulnerability if their guest config file has a 'machine_address_size' setting. ARM systems are not vulnerable. MITIGATION ========== Running only x86 HVM/PVH guests will avoid this vulnerability. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch resolves this issue. xsa284.patch xen-unstable, Xen 4.11.x ... 4.7.x $ sha256sum xsa284* 5359796890fc59dd2bbf8d23398c229153c8b9b716c01842dfb9f95d063a3ad4 xsa284.meta 3a95ae9faef3886fd3a4ed5b22d944939bb2f819bb5a2a8061b2311cf3c05776 xsa284.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. But: 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----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlx+aa0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZwsYH/1yPmIG8vO86sWbX4bvwOsiRQMyy+U/HGKnh3kRi lkDap3srzCRNveh/pqIJQF0okH/gD5VfHZrr3D73cHK7JKmlhoI0bPhpb6oE7/10 SmnaL/cW6/75FuDGdWzmKqx56Y/Ho/wxqGBj69rBbleOnGv+RHUQuGGTZ9g4rmzb Nn4DbVRLz2cqvQhHmwjQBl/unid1BAnHVATHnNdjlF/SgucR7oRweioYjTeoFbZv AdAWXX1GJRoXokGd1uE0eo/Mice/zmlHp//5JADCzo/oPevBFixMw/KWCaCMmUJt FyDNwlu8xtm/bopBWN9dGc2tSKj/0UnTA7FF61OG39BdJHo= =EzAi - -----END PGP SIGNATURE----- ============================================================================= - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory XSA-285 version 2 race with pass-through device hotplug UPDATES IN VERSION 2 ==================== Metadata updated to remove dependency on XSA-283. Public release. ISSUE DESCRIPTION ================= When adding a passed-through PCI device to a domain after it was already started, IOMMU page tables may need constructing on the fly. For PV guests the decision whether a page ought to have a mapping is based on whether the page is writable, to prevent IOMMU access to things like page tables. Writablility of a page may, however, change at any time. Failure of the relevant code to respect this possible race may lead to IOMMU mappings of, in particular, page tables, allowing the guest to alter such page tables without Xen auditing the changes. IMPACT ====== Malicious PV guests can escalate their privilege to that of the hypervisor. VULNERABLE SYSTEMS ================== All versions of Xen are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. Only guests which are assigned a device after domain creation can exploit this vulnerability. Guests which are not assigned devices, or guests assigned devices at domain creation time, cannot exploit this vulnerability. MITIGATION ========== Running only HVM or PVH guests avoids the vulnerability. Assigning passed-through PCI devices to PV guests at domain creation time also avoids the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa285.patch xen-unstable xsa285-4.11.patch Xen 4.7.x - Xen 4.11.x $ sha256sum xsa285* 0851a4a9120220e2b03eafaf94648077154b6a6f27c29055d3779ccad7684fce xsa285.meta 9e96d3763158edde8d664c3e26761e63ca6f96bb921e0d7eb68351fe47499bde xsa285.patch 38ec20b04e0a859abe9850803ae00a33e48591a9949e5287dfa3725f3bd179f3 xsa285-4.11.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. But: 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----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlx+aa0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZhOAIAMZ/Q0Pq2cnicghrabKDMjKUsdyAcbK20sxXdx9y l0abU4kMQcnsejlbGfAhZQaDIpkGZN+rNw0BnC3VBH61en22q3yNlQsxP/eQhGKm du7sdN6DBayqX1Sjdn+UPzrDFTu7JoSsXN9NrHKgVXNS+jKWZOR9yfZBYFAk3RQB R1oYL2OYiyYFibxzNwbiLxzgEhGls38JzDtvTDuN6YBViaWQWgE9aOCzTZ6vOlzn BcZf5fHc6F/zg5xI3FhBYEPfBdAZvno/xJJymxENWegqwhdgfx6uWetT3M6axv89 h0HdmJ5KaMOdD96Tf+CUVI3N7UcVcuyAaMQqJVAM/+gAiU0= =+pPX - -----END PGP SIGNATURE----- ============================================================================= - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory XSA-290 version 2 missing preemption in x86 PV page table unvalidation UPDATES IN VERSION 2 ==================== Metadata updated to remove dependency on XSA-283. Public release. ISSUE DESCRIPTION ================= XSA-273 changes required, among other things, making any PTE updates restartable. The changes making PTE updates restartable assumed that L2 pagetables would always be promoted preemptibly; but this turns out not to be the case when using the 'linear pagetable' feature; the result was that interrupted operations are not handled properly in certain cases. Furthermore, previous security work making pagetable update preemptible failed to account for 'linear pagetables' at L3 and L4 levels, making it possible for operations to run for longer than acceptable times. IMPACT ====== Malicious or buggy x86 PV guest kernels can mount a Denial of Service (DoS) attack affecting the whole system. VULNERABLE SYSTEMS ================== All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only Xen versions which permit linear page table use by PV guests are vulnerable. Only x86 PV guests can leverage this vulnerability. x86 HVM guests cannot leverage this vulnerability. MITIGATION ========== Not permitting linear page table use by PV guests avoids the vulnerability. This can be done both at build time, by turning off the PV_LINEAR_PT configure option, or at runtime, by passing specifying "pv-linear-pt=0" on the hypervisor command line. Doing so would, however, render PV guests using the functionality, like NetBSD, unusable. On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which only issue sane hypercalls will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. Running only HVM guests will avoid this vulnerability. CREDITS ======= This issue was discovered by Manuel Bouyer. RESOLUTION ========== Applying the appropriate pair of attached patches resolves this issue. xsa290/unstable-.patch xen-unstable xsa290/4.11-.patch Xen 4.11.x xsa290/4.10-.patch Xen 4.10.x xsa290/4.9-.patch Xen 4.9.x xsa290/4.8-.patch Xen 4.8.x xsa290/4.7-.patch Xen 4.7.x $ sha256sum xsa290* xsa290*/* e74014bf97f223f35dc6142fbfadd8a3df6c7ecf1818d5d04ebb717a1d600959 xsa290.meta 87ffaf9712bfd2283e845d168811e572b9ebc8a580e750128586a48e65ae4c67 xsa290/4.7-1.patch 4137eb15d963a77ff302cb65f9f04e402ea23f69042f89ece4baaf4b7a58d638 xsa290/4.7-2.patch 0f5ce8c13c99431cae69736e117c7420c3202e3a680b42a66027646ae0aa141c xsa290/4.8-1.patch bb4102dd6f3daf60859a88b6a2f0828bc8aeb224d3d3b6fd2d2cc96b3f131a24 xsa290/4.8-2.patch a7e4902968529289c63149608d48e1eeac2feffa644e1337b1b5b9a624dc746d xsa290/4.9-1.patch 7798b063a8db95fc18bca1ea25d84937fbe9c6e0add15056841fd97d5aec2885 xsa290/4.9-2.patch 3a0bf44875bb5a8525b4418d6efd49bd6ed6cfaffe669cbdcfde61a65fe9cdea xsa290/4.10-1.patch 1e7dfe1b0c57e245daef1351db855a9312a4c225c05a6720460ea4aa1148ee22 xsa290/4.10-2.patch 3dd47f3bc1a004260d05cba548a80e475f85ffe60b663879de386e32a8e9ffbc xsa290/4.11-1.patch b3b17546fc553bf60572cf56023d8177f96973fcd072a8adfc622b4030e58d00 xsa290/4.11-2.patch 4ff1d857f46a781fd7483a30297ebf51bf079ccd1d598df799e5779ddc893674 xsa290/unstable-1.patch 3a85ecc426d482052aaf2a84bfde9840eb7a566638dbab042dac84b0019ca473 xsa290/unstable-2.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or the HVM-only as well as host controlled kernel 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. HOWEVER deployment of the "pv-linear-pt=0" mitigation described above 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 in that case the configuration change is visible to the guest, which could lead to the rediscovery of the vulnerability. But: 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----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlx+amwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZaP0IALeZ9zd5UEHwM2Xq2VTZdJqTW9blhttrJbmfTiSe 7/wtwsMpRIrxycdouWzAZwo3ZFt3Y6qmk+6awkT23ck0OC1zNnMw9ANYdB2XqW+Q NGzz/ExDj+40EeaMcx2ZyNUZGya0yJVorzRSPM68bQAW2XXy1oBevTKqMkr3iSJf I06/J7vtap89F+JjfiBrVXubcjmUvX/MtsD4yz0lckC5Ti07Lcmv0pUGHprxXBgw QlMhgV3qKG3JBa7h0b11UnrpIPdCbwJIWJd/+Pzd4yD9R3ZXRiGyjOd+/zyXVcY7 vCrh2lCP4WpXvrLDUPt8IgJak8cjxZ2JGAxk3yN/QI6Uro0= =/yIK - -----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 auscert@auscert.org.au 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: https://www.auscert.org.au/bulletins/ =========================================================================== Australian Computer Emergency Response Team The University of Queensland Brisbane Qld 4072 Internet Email: auscert@auscert.org.au 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----- Comment: http://www.auscert.org.au/render.html?it=1967 iQIVAwUBXH8sA2aOgq3Tt24GAQiuqw/8CwRDcN6Z8ZnkzBqHHBvflxnBKP0Ba3ao 6Bdla5jRqgzSxd4BR0Q7jlG8PPRXj060OPtw9ahT8xa/E2E5pSAT2PkqfHJupQEH lGwbTHLQkUKBuUpTiDB3utJ6lU2ck9RFx7sbNiMBGcoj1GMUDJhBB8D66/WsHCL1 KAJAoW4xAKExWGRCiTxtA6fDZWaIqZwLbJRjDYI8jwiklhnasg9HdgkA781iELSg 5rK9MFtDbeM2/24HRclfT3nj5mAOPLXKOkT7r36UwLFjfTU7KXdbWZ6t1KcEdfQ6 AG59MAIiDIthcWRXohFYSDX34Km+M3V8vHbzy0+A8NeLzruJnun45HXtwgzZfgVn 9z7D55SuCmPSeKx3Xp0rWPCnu1R30yso2IcWd0xxbOGdDKx52uuDAzVoKwi62HC9 gHgagBMB6dBP8C7drX7Jc2S7CWE8wjPUxOTSWUT+l1aDr1/zrfalZRjjq/L+i2q5 wsvxT9tE8Zmm29o37Ha6V24gQV4DGgFTPbembWEXgcqNGzF2C3m/PcDyjXCp6V1W G1wWEm8RSHrHJHrY/L4/mwQ5ByEJ4u8hkpkciVHp3mLq77qKofheF87VcqOsWF/y rsJu1+Y+fwX74eeVrM005QwdI8W93/jTFKNK1N9lH1Q2/Ck98BpR1+T52vG8VMFy sPdVKAwxceQ= =dk7H -----END PGP SIGNATURE-----