Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2021.2886 New Xen bulletin: inadequate grant-v2 status frames array bounds check 26 August 2021 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Product: Xen Publisher: Xen Operating System: Xen Virtualisation Impact/Access: Increased Privileges -- Existing Account Denial of Service -- Existing Account Access Confidential Data -- Existing Account Resolution: Patch/Upgrade CVE Names: CVE-2021-28699 Original Bulletin: http://xenbits.xen.org/xsa/advisory-382.txt - --------------------------BEGIN INCLUDED TEXT-------------------- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2021-28699 / XSA-382 version 2 inadequate grant-v2 status frames array bounds check UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The v2 grant table interface separates grant attributes from grant status. That is, when operating in this mode, a guest has two tables. As a result, guests also need to be able to retrieve the addresses that the new status tracking table can be accessed through. For 32-bit guests on x86, translation of requests has to occur because the interface structure layouts commonly differ between 32- and 64-bit. The translation of the request to obtain the frame numbers of the grant status table involves translating the resulting array of frame numbers. Since the space used to carry out the translation is limited, the translation layer tells the core function the capacity of the array within translation space. Unfortunately the core function then only enforces array bounds to be below 8 times the specified value, and would write past the available space if enough frame numbers needed storing. IMPACT ====== Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from 4.10 onwards are affected. Xen versions 4.9 and older are not affected. Only 32-bit x86 guests permitted to use grant table version 2 interfaces can leverage this vulnerability. 64-bit x86 guests cannot leverage this vulnerability, but note that HVM and PVH guests are free to alter their bitness as they see fit. On Arm, grant table v2 use is explicitly unsupported. Only guests permitted to have 8177 or more grant table frames can leverage this vulnerability. MITIGATION ========== The problem can be avoided by not increasing too much the number of grants Xen would allow guests to establish. The limit is controlled by the "gnttab_max_frames" Xen command line option and the "max_grant_frames" xl domain configuration setting. - - From Xen 4.14 onwards it is also possible to alter the system wide upper bound of the number of grants Xen would allow guests to establish by writing to the /params/gnttab_max_frames hypervisor file system node. Note however that changing the value this way will only affect guests yet to be created on the respective host. Suppressing use of grant table v2 interfaces for 32-bit x86 guests will also avoid this vulnerability. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa382.patch xen-unstable - Xen 4.11.x $ sha256sum xsa382* 1254d62c8ec2c6b45c117d1483af9a71f5de0e4142c9451dd5a75ee334219542 xsa382.meta 9e500ba2bfe36bebf27262afcb9be7b02f950aed4a7b6c1738606d5ed538c2b8 xsa382.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or grant-frames-limiting mitigation 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, care has to be taken to avoid restricting guests too much, as them suddenly being unable to establish grants they used to be able to establish may lead to re-discovery of the issue. AND: Deployment of the grant table v2 disabling mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change is recognizable by the affected guests. AND: 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/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZwnkIALnDReUPP6qoQzBWHf9s93UPwM6YVdHl/ao1Nh9l IyMGtTKjJjtYR9at0tIJDmVecFZzsBtLhQlKWe5DvNP84ZQ99EGDjzsqYKGdJMZK QIfyUz74UKN5PwEzxeT2C3Q9tOIq2NA41Vax19MjAXSbvAi3jp/0CSj7i6h+bK5f WoBX9Av8Ie2ykF3Fe5i7yNl9gMpCyqEl3dijWwjezLIxlxzdBrjbKni+yBvmLBS9 XdS++bu9LwAbQXeDc5oB0b6mvy+7oHzEJfvCH+tA6o6V6bls94sF8owi5H52rn1n 23HzFQwbwqX9wmW5OKSS/NBzI9vJwzRCyOEVQw+eaZQGiHw= =kWGv - -----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 iQIVAwUBYSctJONLKJtyKPYoAQjNIQ/8Cu1177l+h1As1i6d8u6khSnImDTOhd0O mIMs0nWh/LyPEKE6ijvwSN0DGo8iS3IWRVqRNI7zAeQrf8eLUTd/MylXXibUpk4i pvWzqdJyH+9L2iDllclaUMDW3nkN6noe+KLFO/tenaKaiQci4pAz6OnZCJrfIFng OxKJumb+uKLFXM7p6z0XNRXA6Mog5TjmFAbKzl4nZ0eF502EQ6tFrZtEJ7bAlVo4 q3X06yKSLQdJm8SK6rEOkcD1mSAdF2YwNT575OCn/1sF9V9V/gv+8aoed3UmX4tL YS/Dd/x+b9yaL6hQdjIfgwiXGD7+H7d4dnFHo57/cm9gaba1h61jO1Af9uoix1L7 xmuCi8wjUP+mCJtdajijga1VSrED9QuPrGbZozGiOfgz7Z5hC/tPJuovaJxYAKal qRtGQnHxFkuyUituiBUsKGh7qx2htfA6z5YdOADrxyQ/fhtLbx4LsGBIVPuWSCfA WJeNF6q2yMcGq9vab7MsNjdyCrbQgk6ivb6qw5df9v7gB6JhgFGTOhJGVoH0Kdr7 JM4HCAGhXQyECzKEG7UT6GLbOlIHbvrHoS2SlnY4mZHZwTf+VTUh5RTD5Eh1zMeg CSMOYXhXksCqASm8XBJSdxDqv4nD9bVTgIg6BdKGPr7WwAQUot/QYYayMzkAhj4K DvPUO56SNcg= =MULW -----END PGP SIGNATURE-----