[Xen-devel] Xen Security Advisory 279 v2 - x86: DoS from attempting to use INVPCID with a non-canonical addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-279 version 2 x86: DoS from attempting to use INVPCID with a non-canonical addresses UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The INVPCID instruction raises #GP[0] if an attempt is made to invalidate a non-canonical address. Older flushing mechanisms such as INVLPG tolerate this without error, and perform no action. There is one guest accessible path in Xen where a non-canonical address was passed into the TLB flushing code. This previously had no ill effect, but became vulnerable with the introduction of PCID to reduce the performance hit from the Meltdown mitigations. IMPACT == A buggy or malicious PV guest can crash the host. VULNERABLE SYSTEMS == Only hardware which supports the INVPCID instruction is vulnerable. This is available on Intel Haswell processors and later. AMD x86 processors are not known to support this instruction, and ARM processors are entirely unaffected. Only versions of Xen with PCID support are vulnerable. Support first appeared in Xen 4.11 but was backported to the stable trees as part of the Meltdown (XSA-254 / CVE-2017-5754) fixes. Xen 4.10.2, 4.9.3, 4.8.4 as well as the stable-4.7 and 4.6 branches are vulnerable. The vulnerability is only exposed to 64-bit PV guests. 32-bit PV guests, as well as HVM/PVH guests cannot exploit the vulnerability. MITIGATION == Booting Xen with `pcid=0` or `invpcid=0` on the command line will work around the issue. Alternatively, running untrusted 64bit PV guests inside xen-shim will work around the issue. CREDITS === This issue was discovered by Matthew Daley. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa279.patch xen-unstable, Xen 4.11.x, Xen 4.10.x xsa279-4.9.patch Xen 4.9.x ... 4.7.x $ sha256sum xsa279* 40319fcf33348176eb14d7fc7c68c255cc7291013242ea444de6d00602024a11 xsa279.meta 0c1d50effe6645051a15dd83af57088dd4a055e26a23b1fa9e6c3722a7973f5d xsa279.patch fd34f29bc7e53359585135408cbbd12e12a003f59b135e81cc44186c5cddd40d xsa279-4.9.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/4UyVfoK9kFAlv0C2oMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZKtwH/iNT0SP+by+n+HfWJfl4hZgJ4ZU3ZJDXyxuMchHv ZXYxW9FEab34qjOtRKToIYaPybjULbCNf2EeSmdwuHS55BP+GlnGT27gCU0FSECJ bfCkXFAJh04SjjzInOQxyfMUPmCztnwQvzADPJkxp1+nc++9P66Y44AwzUrRHsT1 A/dryLbZP/WiFyfYBnBPeh8Ib2eaAA1cxWLVbHwYlrrzgwf8pLHtKObW1TiSS/gr inPqwvcU3dwj3OnsB2KuWodgP7cN/YyE/pdCiSiR7xZqcWN5/bdodwARhGTc2XY3 2OLodVSz962xjmCku7YN0ntiuU1C/c7w2dT5KsF9H/mPwl4= =f39b -END PGP SIGNATURE- xsa279.meta Description: Binary data xsa279.patch Description: Binary data xsa279-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 275 v2 - insufficient TLB flushing / improper large page mappings with AMD IOMMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-275 version 2 insufficient TLB flushing / improper large page mappings with AMD IOMMUs UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = In order to be certain that no undue access to memory is possible anymore after IOMMU mappings of this memory have been removed, Translation Lookaside Buffers (TLBs) need to be flushed after most changes to such mappings. Xen bypassed certain IOMMU flushes on AMD x86 hardware. Furthermore logic exists Xen to re-combine small page mappings into larger ones. Such re-combination could have occured in cases when it was not really safe/correct to do so. IMPACT == A malicious or buggy guest may be able to escalate its privileges, may cause a Denial of Service (DoS) affecting the entire host, or may be able to access data it is not supposed to access (information leak). VULNERABLE SYSTEMS == Xen versions from at least 3.2 onwards are affected. Note that the situation is worse in 4.1 and earlier, in that there's no flushing of the TLB at all. Only systems with AMD x86 hardware with enabled IOMMU are affected. ARM and Intel x86 systems, and AMD x86 systems without enabled IOMMU, are not affected. Only systems where physical PCI devices are assigned to untrusted guests are vulnerable. MITIGATION == There is no known mitigation for affected system/guest combinations. CREDITS === This issue was discovered by Paul Durrant of Citrix. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. xsa275-?.patch xen-unstable xsa275-4.11-?.patch Xen 4.11.x ... Xen 4.8.x xsa275-4.7-?.patch Xen 4.7.x $ sha256sum xsa275* b5a02598cd2cffcc2cb59c724eeabb50220fa55f2cbe571726a5228909bf7bfe xsa275.meta 7a3360e61fbb088f7d9f2b92921c9dceb08a1e01563c42ba4cf4afe42fc4 xsa275-1.patch 4783a3abd2d87386ce9a7b790666ad398c5e027a6a146fce6424f0bcbfd8a7c6 xsa275-2.patch 49844d06f24ea129f1a501b4b0d5cb6ec3b288f3a2b41377ce793cc6fc81a788 xsa275-4.7-1.patch 7ea8bf2ff2c8c92cb064a70959a1148229c4577109015bd5aab72603ccb8f7e3 xsa275-4.7-2.patch 15d1aa7528368ed92caf8ea9baf77a406e1de26d0697dafd8a85da0d66eb95dc xsa275-4.11-1.patch 0806e8c904ac9e8eb89404dffd227fcd56da84b7eb0150ee1e9b4bee54a05b4e xsa275-4.11-2.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/4UyVfoK9kFAlv0C2kMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZEmUIAJh8KKnerBI188shqJlCI2yr3qXG75xsnwQSR4Xd 5lIRLQepG92cPkJa6RPWelJY0rHmPTlFj+apO7k4ZOG4WsZkp8vK16pkOiCGP8wI J7UXfdxj9twOEbvLUE+Xe4bJI7/GQ9UbHefZ5LMdive6jYkq20ZUD7nZOBsXDX7r znb6plF62VzhoGvvL2yLyZRnRJfs91bNfnqPZG54tHDPXFTntVZghrIYKW8kboNF LZNi8fMrk0URy6uUkF2YpzLZ+JoMlPMVPEX3c+bx5xFm7xZc37rGmbHaj+L/5ViY 8e+2EEhzIGYI7liTSgKOzlkxolJ08bd/xolVAAo8vNeHjHo= =noV1 -END PGP SIGNATURE- xsa275.meta Description: Binary data xsa275-1.patch Description: Binary data xsa275-2.patch Description: Binary data xsa275-4.7-1.patch Description: Binary data xsa275-4.7-2.patch Description: Binary data xsa275-4.11-1.patch Description: Binary data xsa275-4.11-2.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 277 v2 - x86: incorrect error handling for guest p2m page removals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-277 version 2 x86: incorrect error handling for guest p2m page removals UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The internal function querying a domain's p2m table grabs the p2m lock by default, so that the answer to the query remains true until the caller can act on that information; it is up to the caller then to release the lock. Unfortunately, certain failure paths don't release the lock. IMPACT == A malicious or buggy guest may cause a deadlock, resulting in a DoS (Denial of Service) affecting the entire host. VULNERABLE SYSTEMS == Xen 4.11 and onward are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only systems running untrusted HVM or PVH guests are vulnerable. Systems running only PV guests are not vulnerable. MITIGATION == Running only PV guests will avoid this vulnerability. CREDITS === This issue was discovered by Paul Durrant of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa277.patch xen-unstable, Xen 4.11.x $ sha256sum xsa277* 576cdc05975e43698624b88f7290119dd702b3db8f30f3219754d992d7fef0c6 xsa277.meta c9025e1daaec4081a61f1ed7b96e69cfe8e35bdd5b4fcc0fadc98f71c2e243e2 xsa277.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/4UyVfoK9kFAlv0C2kMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ3W4H/0lfQ3hxNjmYa9soWCkXCFWrRHEt5G11dtL3GE1B E4GbiAWdownHQjhA3okO9yQKDzwY68+hvVZ7YOUNSQ00tZ8j/RWldDZLhbp9JrjI QMriPefk8X6ZVnF6velUZI2dpOIX6NFBZHxPXUKV8A+e9/+OS7e9CEWrSaprHcbt MTHv5evulxl8sPXyVa8e2m2YSdEFU6ylfVyH3m5u3cKBpvbSLFKyQN+MNX8rTmAn +ga3Vj9zehIlDl22nTXCcQHbj75JK0RsDCcH1Glicqm3LZlZ2GXYNe/OiPdLTmwP 8UN8HJhDB2d6w8x4/TV2ad8UGqCJghkxJkqs2RJJdtz8VSo= =CFtL -END PGP SIGNATURE- xsa277.meta Description: Binary data xsa277.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 276 v2 - resource accounting issues in x86 IOREQ server handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-276 version 2 resource accounting issues in x86 IOREQ server handling UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Allocation of pages used to communicate with external emulators did not follow certain principles that are required for proper life cycle management of guest exposed pages. IMPACT == A compromised DM stubdomain may cause Xen to crash, resulting in a DoS (Denial of Service) affecting the entire host. Privilege escalation as well as information leaks cannot be ruled out. VULNERABLE SYSTEMS == Only Xen 4.11 is affected by this vulnerability. Xen 4.10 and older are not affected by this vulnerability. Only systems running HVM guests with their devicemodels in a stubdomain are considered vulnerable. Note that attackers also need to exploit the devicemodel in order to have access to this vulnerability. Arm guests cannot leverage this vulnerability. MITIGATION == Running only PV guests will avoid this vulnerability. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. xsa276/*.patch xen-unstable xsa276-4.11/*.patchXen 4.11.x $ sha256sum xsa276* xsa276*/* efe9f031c5646b111cbfbe35141a7d99eb31ead07c1c6051145abbd9a3def5b9 xsa276.meta 7f77225e3de780a2507714caab5870664634bf9f76215547bebd31a6399a86ef xsa276-4.11/0001-x86-hvm-ioreq-fix-page-referencing.patch c93c66090009833cd11fabe72b523cbdb3467fa104cc97d1855d365881aa7f8e xsa276-4.11/0002-x86-hvm-ioreq-use-ref-counted-target-assigned-shared.patch ef8b89375866821f4a612f600d10834bf65d811b1784a4ee0fde4a3a409501e0 xsa276/0001-x86-hvm-ioreq-fix-page-referencing.patch 75398ec343b9aaebf0c7dc0c5ef5ed7a3f3be0959f1519db5c7f32c44e7a54d3 xsa276/0002-x86-hvm-ioreq-use-ref-counted-target-assigned-shared.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/4UyVfoK9kFAlv0C2kMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZpssH/1YDoUGry3iCsHZnymWqfWFiuddW2U03UPmq/BH+ tZ+HxnOeibVkvsB8g9POxCkSqS77MiFksgUTc0l6qV9zZ+A7glFRzMbKSSnmobul ETP/7AM3UO8H4uSji8P3lfN0l1B/BXetitv6FzogOUTP4iCX1TYfS4eu+UUOTWoj kg3DglZKeLY/eztTnJSOP5VzT09+Ra44IFvCfzz4gMV6Njgj0dZZ1jyBvKNxY3Rs bKiuycHDAzTGWHR6hymGVR73EowTgaboLEjpXTWVYbBvKv8HUp/v5UBzCf3TuPy6 GmtUaS/mtDPRYcgAjYPddGa7euVL6ESV+FNsSrMneJCBgk4= =/tEm -END PGP SIGNATURE- xsa276.meta Description: Binary data xsa276-4.11/0001-x86-hvm-ioreq-fix-page-referencing.patch Description: Binary data xsa276-4.11/0002-x86-hvm-ioreq-use-ref-counted-target-assigned-shared.patch Description: Binary data xsa276/0001-x86-hvm-ioreq-fix-page-referencing.patch Description: Binary data xsa276/0002-x86-hvm-ioreq-use-ref-counted-target-assigned-shared.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 282 v1 - guest use of HLE constructs may lock up host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-282 guest use of HLE constructs may lock up host ISSUE DESCRIPTION = Various Intel CPU models have an erratum listed under the title "Processor May Hang When Executing Code In an HLE Transaction". It describes a potential hang when using instructions with the XACQUIRE prefix on the host physical memory range covering the first 4 MiB starting at the 1GiB boundary. IMPACT == A malicious or buggy guest may cause a CPU to hang, resulting in a DoS (Denial of Service) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions are affected. Only Intel based x86 systems are affected. Please refer to Intel documentation as to which specific CPU models are affected. AMD x86 systems as well as Arm ones are not affected. MITIGATION == There is no known mitigation. A BIOS update may be available for some systems, working around the issue at the firmware level. RESOLUTION == Applying the appropriate pair of attached patches works around this issue for the CPU models known to be affected at the time of writing. xsa282-?.patch xen-unstable xsa282-4.11-1.patch + xsa282-2.patchXen 4.11.x, Xen 4.10.x xsa282-4.9-1.patch + xsa282-2.patch Xen 4.9.x xsa282-4.9-1.patch + xsa282-4.8-2.patch Xen 4.8.x, Xen 4.7.x $ sha256sum xsa282* 6ef64ca920a58ed9185e81fad3dfa9ca5f6316f1e72ddd4f411f3e79eaf79903 xsa282.meta ad7093e00b3d6650530c95427ef0e68880883f0cec7229b5f41c9e2dc497ffd5 xsa282-1.patch 7ce7fa105026b189500a31bd3978ec0c6fd9d7c95f688463c25ecce76366be35 xsa282-2.patch fbff734d678700864563f8214361f391c0cbda9b67ed7256535ed3db388c8feb xsa282-4.8-2.patch df833cbe9b8798104a65d44b737c46f97399b86b0ffd03c99fda4c8ecf5a353c xsa282-4.9-1.patch 68eab296a7124662cbe3c6df8835aff9b4a26160fdbe970e206a7a6ef8d27ec7 xsa282-4.11-1.patch $ NOTE REGARDING LACK OF EMBARGO == The issue has been documented publicly in Specification Updates for at least some of the affected processors for quite some time. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlvh3+0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ48QIALQ1hLMewraf+URzsd36EUJNPP+1C8Dg35PavdJ1 mrqBljy/bIYCiLvLm1RwinUPL5vrvkB97/6AjmnpZM83AA3/PLTbh3tpP8fiLUcF YL7wJogvjv51Q3N8mYHjxGGl5YYVdrgxwxbQIuzRnw2gi/ikd0oAoNce/QIF6iFz P2I8VjKuQZ6qEzdKXTTiPNQQzL+OfVGQ+RcsthQieWce53p+n1pI1QqbPOwdYtca /cOhP+vGRzh+4QP50JuN5ikdC/C9KpyjEo5mZVlrZQYPIqzI+vomueCJLPGN3cSY LBcJc/lT/w/LRgygpbUB/OO8RwK5XB9T4Jm/ssXGpCOTs3Y= =Ipfd -END PGP SIGNATURE- xsa282.meta Description: Binary data xsa282-1.patch Description: Binary data xsa282-2.patch Description: Binary data xsa282-4.8-2.patch Description: Binary data xsa282-4.9-1.patch Description: Binary data xsa282-4.11-1.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 278 v2 (CVE-2018-18883) - x86: Nested VT-x usable even when disabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-18883 / XSA-278 version 2 x86: Nested VT-x usable even when disabled UPDATES IN VERSION 2 CVE assigned. ISSUE DESCRIPTION = When running HVM guests, virtual extensions are enabled in hardware because Xen is using them. As a result, a guest can blindly execute the virtualisation instructions, and will exit to Xen for processing. In the case that the guest hasn't followed the correct (virtual) configuration procedure, it shouldn't be able to use the instructions, and Xen should respond with #UD exception. When nested virtualisation is disabled for the guest, it is not permitted to complete the configuration procedure. Unfortunately, when nested virtualisation is intended to be disabled for the guest, an incorrect default value leads Xen to believe that the configuration procedure has already been completed. IMPACT == Guest software which blindly plays with the VT-x instructions can cause Xen to operate on uninitialised data. As the backing memory is zeroed, this causes Xen to suffer a NULL pointer dereference, causing a host Denial of Service. Other behaviours such as memory corruption or privilege escalation have not been ruled out. VULNERABLE SYSTEMS == Systems running Xen 4.9 or later are vulnerable. Systems running Xen 4.8 or earlier are not vulnerable. Only Intel x86 systems are vulnerable. Systems from other x86 vendors, and other hardware vendors are not vulnerable. Only x86 HVM and PVH guests can leverage this vulnerability. x86 PV guests cannot leverage this vulnerability. MITIGATION == Running only x86 PV guests will avoid the issue. For x86 HVM guests, while enabling nested virtualisation for affected guests does work around this particular DoS, it is not a security supported configuration and has other know DoS and suspected privilege escalation vulnerabilities. Therefore, it is not a mitigation. CREDITS === This issue was discovered by Sergey Dyasli of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa278.patch xen-unstable xsa278-4.11.patch Xen 4.11, 4.10, 4.9 $ sha256sum xsa278* d94c59ee170f96af14f0cf696221ba8b9447b86820fe99fba1815ab93cc89cd7 xsa278.patch 22686a9bbfbd38bb74292a28a452012d263875c9064815d4afd3fd6c62df0c3a xsa278-4.11.patch $ NOTE CONCERNING LACK OF EMBARGO === This issue was first reported in private and was in the usual XSA process. It was later independently reported in public with enough detail for the issue to be considered fully public. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlva3xQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ2DUIAKIKRyJ9tb1+t8FVECYVR6L5JjhVjyiC1HKnmmGO o+Fl1glQZqK1b5oKkV58jNf32wUOjhlHut1iXJmuE7VGrBsSzj4ew3wIwFcAeTyL nykIFtS8YBlodQfcd7XRyh030bQ5f5JtJYTyJTpAwor8JQrVJH+lYdv+zddPfVbp sUMXFrSxAmnzhrYKuUHNZ438O6+PwunPROTng6VRmreutqnxjnvxtmLqJLk23gvI jfg8THSawEREg9R6cjpO8ZmfouukTJp7t5mmte1g8kJm/UJ4iRWAS67tYF6m4V+K 1H7Sc0E4yV8I/PL46V+53r43NcCtPFP+GM/AaIzggov2Hn0= =el52 -END PGP SIGNATURE- xsa278.patch Description: Binary data xsa278-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 278 v1 - x86: Nested VT-x usable even when disabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-278 x86: Nested VT-x usable even when disabled ISSUE DESCRIPTION = When running HVM guests, virtual extensions are enabled in hardware because Xen is using them. As a result, a guest can blindly execute the virtualisation instructions, and will exit to Xen for processing. In the case that the guest hasn't followed the correct (virtual) configuration procedure, it shouldn't be able to use the instructions, and Xen should respond with #UD exception. When nested virtualisation is disabled for the guest, it is not permitted to complete the configuration procedure. Unfortunately, when nested virtualisation is intended to be disabled for the guest, an incorrect default value leads Xen to believe that the configuration procedure has already been completed. IMPACT == Guest software which blindly plays with the VT-x instructions can cause Xen to operate on uninitialised data. As the backing memory is zeroed, this causes Xen to suffer a NULL pointer dereference, causing a host Denial of Service. Other behaviours such as memory corruption or privilege escalation have not been ruled out. VULNERABLE SYSTEMS == Systems running Xen 4.9 or later are vulnerable. Systems running Xen 4.8 or earlier are not vulnerable. Only Intel x86 systems are vulnerable. Systems from other x86 vendors, and other hardware vendors are not vulnerable. Only x86 HVM and PVH guests can leverage this vulnerability. x86 PV guests cannot leverage this vulnerability. MITIGATION == Running only x86 PV guests will avoid the issue. For x86 HVM guests, while enabling nested virtualisation for affected guests does work around this particular DoS, it is not a security supported configuration and has other know DoS and suspected privilege escalation vulnerabilities. Therefore, it is not a mitigation. CREDITS === This issue was discovered by Sergey Dyasli of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa278.patch xen-unstable xsa278-4.11.patch Xen 4.11, 4.10, 4.9 $ sha256sum xsa278* d94c59ee170f96af14f0cf696221ba8b9447b86820fe99fba1815ab93cc89cd7 xsa278.patch 22686a9bbfbd38bb74292a28a452012d263875c9064815d4afd3fd6c62df0c3a xsa278-4.11.patch $ NOTE CONCERNING LACK OF EMBARGO === This issue was first reported in private and was in the usual XSA process. It was later independently reported in public with enough detail for the issue to be considered fully public. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlvQ4AQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZMncIAKPKEhtKfaVxNp3WxA2UYRYQCLjrPieFwn8WF/Bx Fcou5sCUhKZuRQccM5sOyDT8q/GRwYcvkcn3yXqXCKkijhsEA4fzsDYrCvQlO7RS xcRMJSBhovz81PPrlDfGVGB6f2Iq3JePVP9DNxwHhgNQJN0+3kdjzEUtKJx3VczE 8LwIpQYyG4Xn3HBIjVD7R6+UiJLcDrD5sdRh9yOgNFNQQUqERtsAOEFJ2raYs/Cm hUvb5m3HBJSzcsZqdfTe5ovLwpumNygao43xt+lAA1KvKk148yEjO4E1dIklmFOE 1d6Za6n9VD/+vTAo2JMDr0WpHZjzvBxNHkOg4levkYvKiCg= =fPmO -END PGP SIGNATURE- xsa278.patch Description: Binary data xsa278-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 270 v3 (CVE-2018-15471) - Linux netback driver OOB access in hash handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15471 / XSA-270 version 3 Linux netback driver OOB access in hash handling UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Linux's netback driver allows frontends to control mapping of requests to request queues. When processing a request to set or change this mapping, some input validation was missing or flawed. IMPACT == A malicious or buggy frontend may cause the (usually privileged) backend to make out of bounds memory accesses, potentially resulting in one or more of privilege escalation, Denial of Service (DoS), or information leaks. VULNERABLE SYSTEMS == Linux kernel versions from 4.7 onwards are affected. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Felix Wilhelm of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa270.patch Linux 4.7 ... 4.17 $ sha256sum xsa270* 392868c37c1fe0d16c36086208fd0fc045c1baf8ab9b207995bce72681cb8c54 xsa270.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- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4MAAoJEIP+FMlX6CvZOpsH/34RpIZaTTVsZWCVyNotieFf yLfCqu+9bbRVNEqYDq6NViFrj9I6WwvLpp8s7HZheJvdXlyIO1cYCen4QX8VSPqI VaRD7Jcu99drK1hy/t80AbicS+t9qvew97SzjG+MIIJZK7dnxG/Q0nbHLCg0zdCg 5G+pOTl17DK+4eM7Z1duo2BK1sxCms6I/YJVFfkGjC99vXKYAj2GAWGxVbiEwDWT 4jvf3R3w5athJNR4Lf6FxDz6MzvHaYNFQKikc0AMaTcO5HubumGXQQn5JQelAAno O6ujB25kF1j29A2PwYvBSxBDTD4uWQeWiv9kWML1YmzsQv1cy6Un0vwXtNhhb6s= =SC+y -END PGP SIGNATURE- xsa270.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 272 v3 (CVE-2018-15470) - oxenstored does not apply quota-maxentity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15470 / XSA-272 version 3 oxenstored does not apply quota-maxentity UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 "Operations on data structures" of the OCaml manual: http://caml.inria.fr/pub/docs/manual-ocaml/expr.html the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently. IMPACT == oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS. VULNERABLE SYSTEMS == Xen 4.1 and later are potentially vulnerable. Only systems using the OCaml xenstored implementation are potentially vulnerable. Systems using the C xenstored implementation are not vulnerable. Whether the compiled oxenstored binary is vulnerable depends on which compiler was used. OCaml can be compiled either as bytecode (with ocamlc) or as a native binary (with ocamlopt). The following OCaml program demonstrates the issue, and identifies whether the resulting oxenstored binary will skip the quota enforcement. $ cat order.ml let check () = let flag = ref false in let update _ = flag := true; () in List.iter update [1;2;3], !flag let main () = let _, flag = check () in if flag then print_endline "This code is not vulnerable!" else print_endline "This code is vulnerable!" let () = main () $ ocamlc order.ml -o order.bytecode $ ./order.bytecode This code is vulnerable! $ ocamlopt order.ml -o order.native $ ./order.native This code is not vulnerable! To confirm whether an OCaml binary is bytecode or native, use file. $ file order.bytecode order.bytecode: a /usr/bin/ocamlrun script executable (binary data) $ file order.native order.native: ELF 64-bit LSB executable, ... NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in Debian Jessie. These results are not representative of other versions of OCaml, or of other OS distributions. MITIGATION == There are no mitigations available. CREDITS === This issue was discovered by Christian Lindig of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa272.patch All versions of Xen $ sha256sum xsa272* 0da953ca48d0cf0688ecff6a074304a9d2217871809a76ef26b9addeb66ecb3e xsa272.meta 6e0359d89bf65794f16d39198cc90f5c3137bce4eb850e54625ab00e2c568c2c xsa272.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- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4OAAoJEIP+FMlX6CvZCO8H/Rj7Z+rFSuQAVEUKXvvV3lvJ rytocZDTAIduyiBundcbdkcxfCuun6Tqw8ScPJXtml82P8YE+R/ix1hMLcQdYblt tj3qftb6KtjFibctoc0sSLsfjhl2oJC2VjQR3HdixfMlSxEzLkCC3I21fteYs9fp ahO7dByNHFTufbb9GpB+DANmIJ5hwMXxCinvts/L2MP/CCRfb4w5+aTARCQ3UHpX 3/r2wJxLnf4sNpBhHNsArROy8wS+ad0i4XC2fef/Bdye+NRbeICJNqof9fcGjWwE fZRyeNVSk33DuuRz2HI4aoEKAQ/v3b3KLXnfVZY5F5z6Z8j9rie42RI8VDO8Mzc= =Y10L -END PGP SIGNATURE- xsa272.meta Description: Binary data xsa272.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 269 v3 (CVE-2018-15468) - x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15468 / XSA-269 version 3 x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The DEBUGCTL MSR contains several debugging features, some of which virtualise cleanly, but some do not. In particular, Branch Trace Store is not virtualised by the processor, and software has to be careful to configure it suitably not to lock up the core. As a result, it must only be available to fully trusted guests. Unfortunately, in the case that vPMU is disabled, all value checking was skipped, allowing the guest to chose any MSR_DEBUGCTL setting it likes. IMPACT == A malicious or buggy guest administrator can lock up the entire host, causing a Denial of Service. VULNERABLE SYSTEMS == Xen versions 4.6 and later are vulnerable. Only systems using Intel CPUs are affected. ARM and AMD systems are unaffected. Only x86 HVM or PVH guests can exploit the vulnerability. x86 PV guests cannot exploit the vulnerability. MITIGATION == Running only x86 PV guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa269.patch xen-unstable xsa269-4.11.patch Xen 4.11 xsa269-4.10.patch 4.10, 4.9 xsa269-4.8.patch Xen 4.8, 4.7, 4.6 $ sha256sum xsa269* 4733d09bb63523744ca2ee172e2fade0c39082c15d9a746144f279cf1359b723 xsa269.meta 5a5fe36f1f876a5029493e7fa191436fd021929aaba2d820636df17f4ed20113 xsa269.patch ea11cef818050bca13d4eb89294627c97e4cdb830124f679e77d37a44a370286 xsa269-4.8.patch 45ba1823530f329dd73088b77098e686b32f5daac0bc5177b2afea09f8c3593a xsa269-4.10.patch e0ca060311fb9ba3247e2fe65bca4806a131644f8894fd08be374904904b1944 xsa269-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- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4KAAoJEIP+FMlX6CvZfakIAJRgw9LWW7fnr0WX11dt/Rm1 GgBxMWS7DrnBPBjE7GqhtqgFyvIVHBnWEEj1WW1WvHWIV/XIbV8GKOi6ecfF5p3o vK/a/8S0qOSOtOPZZJkZGuZn6pNd9V0Ynx296Hn6DKildBBEkGSXoWo67ViaxrP2 iPzhYukDRYlqjF5pYfPr7Zek+RodtB+rxJEKMpDDIW8aeA3hnsOZNXAmr5n+Q465 rNojqJDV5Zwuli+L0SVzmtkY6dbeXyhMWn3zAj8a5Pq+/VkK3PdcEBVNADLXbh3a lnDmjwsY9ZX64HhXbamFMV1Wykhbjb+Jprj6CJjuz4wcGArKW+lsTV86p8Q5Kzk= =uYjg -END PGP SIGNATURE- xsa269.meta Description: Binary data xsa269.patch Description: Binary data xsa269-4.8.patch Description: Binary data xsa269-4.10.patch Description: Binary data xsa269-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 268 v3 (CVE-2018-15469) - Use of v2 grant tables may cause crash on ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-15469 / XSA-268 version 3 Use of v2 grant tables may cause crash on ARM UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = ARM never properly implemented grant table v2, either in the hypervisor or in Linux. Unfortunately, an ARM guest can still request v2 grant tables; they will simply not be properly set up, resulting in subsequent grant-related hypercalls hitting BUG() checks. IMPACT == An unprivileged guest can cause a BUG() check in the hypervisor, resulting in a denial-of-service. VULNERABLE SYSTEMS == Only ARM systems are vulnerable. All supported versions of Xen are vulnerable. MITIGATION == None. CREDITS === This issue was discovered by 王磊 of Samsung. RESOLUTION == Applying the appropriate attached patch resolves this issue by preventing a guest from switching to grant v2. xsa268.patch xen-unstable xsa268-4.11.patch Xen 4.11.0 xsa268-4.10-?.patchXen 4.10.x xsa268-4.9-?.patch Xen 4.9.x, Xen 4.8.x xsa268-4.7-?.patch Xen 4.7.x xsa268-4.6-?.patch Xen 4.6.x $ sha256sum xsa268* f336b45676e73f8b102e5dddf78af2d1d288f9a254142a8a8e9949db55e1cc3b xsa268.meta ca5f69cb8cfb74fae44a0f39f80ec9ae4d269c4895f36311b50d191be97bbcf0 xsa268.patch 93a68a5b23aedc6adf0aae23303dc8eb2c02dc40a5e1d7eb0a1b497cd66da209 xsa268-4.6-1.patch 5b74afd13d96779a72dc34ba7c63a1735cd267fb9bb643f735ac69b0e6ff54d5 xsa268-4.6-2.patch 820e1018f76ef2828b1cbb33e2966b99f6934a80ab55f11749ff847d375d1b02 xsa268-4.7-1.patch 233f7e69e5fb931d2e5cf03f4407f38ff960c039c9eced957df13d3cc37fa6b1 xsa268-4.7-2.patch 4a0c705f0266185b32daf313e686abc340e2fbb1a1644647500fc405bc180913 xsa268-4.9-1.patch ce16eaab94cd1e64f9c9127b64da7ebb6a7758eb540fecc3bbcc2dbfbcc4d7e2 xsa268-4.9-2.patch f413d41fadefe0e275c8bff16a2061bb325f3900b7ccf214a9e97fabf3ee1a89 xsa268-4.10-1.patch 531654f82908c1aa7b0fcea818c82c4b53d4750a697db3353cc05e9e91e5d639 xsa268-4.10-2.patch baeb6b2c28a9cbe929c9cf34398780002fffe12b928df4d1e5951c0a5b51336a xsa268-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- Version: GnuPG v1 iQEcBAEBCAAGBQJbeo4HAAoJEIP+FMlX6CvZxYMH/R1pB/0Qh+eYJevI0XZCh0TX TlzPkzvTkif3JUfYtms1rVeXdAUoOaZPrMpzZYFWthOHhHR6Y8tiBWxiRGWuEf0a OaAYTebIQN4U69AUXGaXdA1p1Nnix5guOgljM1EHD3LGEBtadzdYdFfpKrEv1F7L f8fwLULljcfwHKI7Yv/CwGdRAt2YrtIFqry916yc0RHk2nQpLvX8V+8YXWla8zGR 1Vkin0WoR31qkcakJGXO8jXD1Wpn4J+2lAyMpAiPpN7d8F7/cEOj7huRuTkYFQha /sTUc5Dy3kniLptJF+2//dLOjwKQKSKd3c8LJjc8IGPCwfpNpVmLaCiB/93AcWk= =yh+i -END PGP SIGNATURE- xsa268.meta Description: Binary data xsa268.patch Description: Binary data xsa268-4.6-1.patch Description: Binary data xsa268-4.6-2.patch Description: Binary data xsa268-4.7-1.patch Description: Binary data xsa268-4.7-2.patch Description: Binary data xsa268-4.9-1.patch Description: Binary data xsa268-4.9-2.patch Description: Binary data xsa268-4.10-1.patch Description: Binary data xsa268-4.10-2.patch Description: Binary data xsa268-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 274 v3 (CVE-2018-14678) - Linux: Uninitialized state in x86 PV failsafe callback path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-14678 / XSA-274 version 3 Linux: Uninitialized state in x86 PV failsafe callback path UPDATES IN VERSION 3 Fix spelling in CREDITS. ISSUE DESCRIPTION = Linux has a `failsafe` callback, invoked by Xen under certain conditions. Normally in this failsafe callback, error_entry is paired with error_exit; and error_entry uses %ebx to communicate to error_exit whether to use the user or kernel return path. Unfortunately, on 64-bit PV Xen on x86, error_exit is called without error_entry being called first, leaving %ebx with an invalid value. IMPACT == A rogue user-space program could crash a guest kernel. Privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Only 64-bit x86 PV Linux systems are vulnerable. All versions of Linux are vulnerable. MITIGATION == Switching to HVM or PVH guests will mitigate this issue. CREDITS === This issue was discovered by M. Vefa Bicakci, and recognized as a security issue by Andy Lutomirski. RESOLUTION == Applying the appropriate attached patch resolves this issue. NB this patch has not been accepted into Linux upstream yet. An updated advisory will be sent if the fix upstreamed looks significantly different. xsa274-linux-4.17.patch Linux 4.17 $ sha256sum xsa274* 0c30cb13d1d573f446c8cb8d4824ffad8ef9149a7589a19ef9bcc83c07bddcf5 xsa274-linux-4.17.patch $ NOTE ON THE LACK OF EMBARGO === The patch for this issue was published on linux-kernel without being first reported to the XenProject Security Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbdFA5AAoJEIP+FMlX6CvZWQQIAIxMK2w6CsH2aNQRDiDrgcBc 2FkBbroS5I1XHEhWVyO19aPhp1R3mYNU+pTUUFOevQuKvTP0nuZ0csgk5LUj9UP7 EE/3vM3jkAfmIIuXCAegOcznnEl6Wi9aMKGVXcxMkRu9qjKStGr4We5qvmdPncUj DkTdD6VbmM/Q665b0jU4j2aZPDMsH63qrsbz1rsnPAlYUi1R+yKw56Q5UdRJK17j Jc74v+elyqOkFq7QwH1usfnko+DQziLyLqEBQOztTSps2qYM+VwHLAZkhxNyuLsu 2x9/1D8XoZ+BHvVsVe50QmoNcJViMMunnHNhWYHmtXLYFErwUOt48N1vl+3xFpo= =k4Ak -END PGP SIGNATURE- xsa274-linux-4.17.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 272 v2 - oxenstored does not apply quota-maxentity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-272 version 2 oxenstored does not apply quota-maxentity UPDATES IN VERSION 2 Ammend patch to reference XSA-272 in the commit message. Public release. ISSUE DESCRIPTION = The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 "Operations on data structures" of the OCaml manual: http://caml.inria.fr/pub/docs/manual-ocaml/expr.html the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently. IMPACT == oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS. VULNERABLE SYSTEMS == Xen 4.1 and later are potentially vulnerable. Only systems using the OCaml xenstored implementation are potentially vulnerable. Systems using the C xenstored implementation are not vulnerable. Whether the compiled oxenstored binary is vulnerable depends on which compiler was used. OCaml can be compiled either as bytecode (with ocamlc) or as a native binary (with ocamlopt). The following OCaml program demonstrates the issue, and identifies whether the resulting oxenstored binary will skip the quota enforcement. $ cat order.ml let check () = let flag = ref false in let update _ = flag := true; () in List.iter update [1;2;3], !flag let main () = let _, flag = check () in if flag then print_endline "This code is not vulnerable!" else print_endline "This code is vulnerable!" let () = main () $ ocamlc order.ml -o order.bytecode $ ./order.bytecode This code is vulnerable! $ ocamlopt order.ml -o order.native $ ./order.native This code is not vulnerable! To confirm whether an OCaml binary is bytecode or native, use file. $ file order.bytecode order.bytecode: a /usr/bin/ocamlrun script executable (binary data) $ file order.native order.native: ELF 64-bit LSB executable, ... NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in Debian Jessie. These results are not representative of other versions of OCaml, or of other OS distributions. MITIGATION == There are no mitigations available. CREDITS === This issue was discovered by Christian Lindig of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa272.patch All versions of Xen $ sha256sum xsa272* 0da953ca48d0cf0688ecff6a074304a9d2217871809a76ef26b9addeb66ecb3e xsa272.meta 6e0359d89bf65794f16d39198cc90f5c3137bce4eb850e54625ab00e2c568c2c xsa272.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- Version: GnuPG v1 iQEcBAEBCAAGBQJbcw8fAAoJEIP+FMlX6CvZ1VYIALce26h9Sf0P0joLd/fhUwf4 JcCIaTWvHsy0ucJgpi7i+SCMa7Iz60CriK6dSYlwIuPvka8XU5MDmZ56gbENApDZ ibWMwvyCrgb0BH3VIwJZfk7eaKM7OwKeEnnIrIWaVGsT2StwoZOHgdLRLCTSFJ/K iss3ALSzZ8z7/WqEkBE3JeJ7skrh5nmNp428fJXWYhOyYbqkqyggn6XzBQg/EzGD vabxz4CdYCr1ox7sq42Q/UFeLoWB6CKCLgRgqOGyCrm7K324ymBzRXtXpPUrLEaq ugR27W/zr09e8N/fOhH4dBNCzkktuqclwrfMlFr1WUfiltSDmVwNZkURkvVGeu0= =TPZD -END PGP SIGNATURE- xsa272.meta Description: Binary data xsa272.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 271 v2 (CVE-2018-14007) - XAPI HTTP directory traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-14007 / XSA-271 version 2 XAPI HTTP directory traversal UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = XAPI has an unauthenticated HTTP endpoint update/ which exports the contents of /var/update for other hosts to use. However, the resolution of . and .. in paths is performed before url unquoting is performed. This allows an attacker to traverse out of the web root. IMPACT == An unauthenticated user with access to the management network can read arbitrary files from the dom0 filesystem. This includes the pool secret /etc/xensource/ptoken which grants the attacker full administrator access. VULNERABLE SYSTEMS == All versions of XAPI since v1.13.0 are vulnerable. If the directory /var/update doesn't exist, the vulnerability is not exposed. MITIGATION == In the recommended configuration, the management network is isolated and isn't reachable from untrusted hosts, or by general network traffic. CREDITS === This issue was discovered by Ronald Volgers of Computest https://www.computest.nl/en/ RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa271-xapi.patch $ sha256sum xsa271* ffefb71cd328e0ee5654c135bf9b08f48abedd013f1c68d5589132e2a03a01f8 xsa271-xapi.patch $ REGENERATION OF POOL SECRET === There are no known exploits in the wild. If there is a risk that credentials could have been stolen, they should be reset. Most credentials can be reset via normal administrative means, but the pool secret doesn't have any mechanism to reset. The following instructions should be used: 1) On all pool members, stop Xapi: # service xapi stop 2) On the pool master: # rm /etc/xensource/ptoken # /opt/xensource/libexec/genptoken -f -o /etc/xensource/ptoken 3) Copy /etc/xensource/ptoken to all pool slaves 4) On the pool master, restart the toolstack: # xe-toolstack-restart 5) On all pool slaves, restart the toolstack: # xe-toolstack-restart Once the pool secret has been regenerated, the root password can be changed with: # xe user-password-change Furthermore, consideration should be given to other credentials, such as (but not limited to) SSL keys, Storage SAN/iSCSI/NFS details, as well as secrets contained within VMs disks/snapshots/etc. 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- Version: GnuPG v1 iQEcBAEBCAAGBQJbcw6vAAoJEIP+FMlX6CvZx6cH/0qaq4PDDHSrIONP7v35ZYWe nZEoA+IWk0u35t4MwSRA8qcXZ9m+d7icHdE0c5Jwdh2sBOSFKzoehCuZOFXVpYTv SHdr/J3ilZRN1KV7Zo/agZJFYClV5QxR118PnVYFqsAHVGjxh6RzazyBNPUTkoIa qw/FBQwsib4Wkj5/RPympYscxetzAUoYiFeVtTgtqknXlt3UbXqzwg/lXTrMZwtG nBSjFEW+EURlkKR0HF85mtFBmqA1I3xsKgJDaob5KWl+HmlIj0SY9knQ2le3lgxn 7zXiPSwOARg2E+vl3GB1Xd1fgcRGykBtjVWPX9uAgdb/C7qx6DN2PYEdyz1xZtI= =5lIm -END PGP SIGNATURE- xsa271-xapi.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 268 v2 - Use of v2 grant tables may cause crash on ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-268 version 2 Use of v2 grant tables may cause crash on ARM UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = ARM never properly implemented grant table v2, either in the hypervisor or in Linux. Unfortunately, an ARM guest can still request v2 grant tables; they will simply not be properly set up, resulting in subsequent grant-related hypercalls hitting BUG() checks. IMPACT == An unprivileged guest can cause a BUG() check in the hypervisor, resulting in a denial-of-service. VULNERABLE SYSTEMS == Only ARM systems are vulnerable. All supported versions of Xen are vulnerable. MITIGATION == None. CREDITS === This issue was discovered by 王磊 of Samsung. RESOLUTION == Applying the appropriate attached patch resolves this issue by preventing a guest from switching to grant v2. xsa268.patch xen-unstable xsa268-4.11.patch Xen 4.11.0 xsa268-4.10-?.patchXen 4.10.x xsa268-4.9-?.patch Xen 4.9.x, Xen 4.8.x xsa268-4.7-?.patch Xen 4.7.x xsa268-4.6-?.patch Xen 4.6.x $ sha256sum xsa268* f336b45676e73f8b102e5dddf78af2d1d288f9a254142a8a8e9949db55e1cc3b xsa268.meta ca5f69cb8cfb74fae44a0f39f80ec9ae4d269c4895f36311b50d191be97bbcf0 xsa268.patch 93a68a5b23aedc6adf0aae23303dc8eb2c02dc40a5e1d7eb0a1b497cd66da209 xsa268-4.6-1.patch 5b74afd13d96779a72dc34ba7c63a1735cd267fb9bb643f735ac69b0e6ff54d5 xsa268-4.6-2.patch 820e1018f76ef2828b1cbb33e2966b99f6934a80ab55f11749ff847d375d1b02 xsa268-4.7-1.patch 233f7e69e5fb931d2e5cf03f4407f38ff960c039c9eced957df13d3cc37fa6b1 xsa268-4.7-2.patch 4a0c705f0266185b32daf313e686abc340e2fbb1a1644647500fc405bc180913 xsa268-4.9-1.patch ce16eaab94cd1e64f9c9127b64da7ebb6a7758eb540fecc3bbcc2dbfbcc4d7e2 xsa268-4.9-2.patch f413d41fadefe0e275c8bff16a2061bb325f3900b7ccf214a9e97fabf3ee1a89 xsa268-4.10-1.patch 531654f82908c1aa7b0fcea818c82c4b53d4750a697db3353cc05e9e91e5d639 xsa268-4.10-2.patch baeb6b2c28a9cbe929c9cf34398780002fffe12b928df4d1e5951c0a5b51336a xsa268-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- Version: GnuPG v1 iQEcBAEBCAAGBQJbcw6rAAoJEIP+FMlX6CvZ+i0H/0E0ezqXT58ivMM4QAGo5kkc jlJH1WikhqPYEaZ2XSLDSOj9Ukllfc3WKokxMCZJzFZPtjCBFd5ClVikDNiUotl3 tOyHTh+qQrVasWWZq0MG6vg+yCMBrVXolY8K7YgfT9A+nbkzaTTsTGTMKVKZwGDI jXoUUtkYn0n3OlnbNYYV3GcCTvfLnXxSAGzC+0NxjrKR4lXjZ/dT0U5eQerZfNha bEsP7Stt4B+ITWNIuMxLPYGNKNHq65gaTNmBQbxRE0lRdn8N5Q5KNeccpOhOKJMi U+ZhZ8cLEN1wNyZItO/MMB/zjVZwYaYxPYyKXAaf9uU21oOGFO6vrnF8f9oKlnQ= =ocO0 -END PGP SIGNATURE- xsa268.meta Description: Binary data xsa268.patch Description: Binary data xsa268-4.6-1.patch Description: Binary data xsa268-4.6-2.patch Description: Binary data xsa268-4.7-1.patch Description: Binary data xsa268-4.7-2.patch Description: Binary data xsa268-4.9-1.patch Description: Binary data xsa268-4.9-2.patch Description: Binary data xsa268-4.10-1.patch Description: Binary data xsa268-4.10-2.patch Description: Binary data xsa268-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 269 v2 - x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-269 version 2 x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The DEBUGCTL MSR contains several debugging features, some of which virtualise cleanly, but some do not. In particular, Branch Trace Store is not virtualised by the processor, and software has to be careful to configure it suitably not to lock up the core. As a result, it must only be available to fully trusted guests. Unfortunately, in the case that vPMU is disabled, all value checking was skipped, allowing the guest to chose any MSR_DEBUGCTL setting it likes. IMPACT == A malicious or buggy guest administrator can lock up the entire host, causing a Denial of Service. VULNERABLE SYSTEMS == Xen versions 4.6 and later are vulnerable. Only systems using Intel CPUs are affected. ARM and AMD systems are unaffected. Only x86 HVM or PVH guests can exploit the vulnerability. x86 PV guests cannot exploit the vulnerability. MITIGATION == Running only x86 PV guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa269.patch xen-unstable xsa269-4.11.patch Xen 4.11 xsa269-4.10.patch 4.10, 4.9 xsa269-4.8.patch Xen 4.8, 4.7, 4.6 $ sha256sum xsa269* 4733d09bb63523744ca2ee172e2fade0c39082c15d9a746144f279cf1359b723 xsa269.meta 5a5fe36f1f876a5029493e7fa191436fd021929aaba2d820636df17f4ed20113 xsa269.patch ea11cef818050bca13d4eb89294627c97e4cdb830124f679e77d37a44a370286 xsa269-4.8.patch 45ba1823530f329dd73088b77098e686b32f5daac0bc5177b2afea09f8c3593a xsa269-4.10.patch e0ca060311fb9ba3247e2fe65bca4806a131644f8894fd08be374904904b1944 xsa269-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- Version: GnuPG v1 iQEcBAEBCAAGBQJbcw6sAAoJEIP+FMlX6CvZNaQIAIPnev8ld7Rt9Gaty0mymCq8 WkKMRcqqSTbmHCgFvsWPPoji9yqQZR5QMkb+q7voE7PvzqH5sTAP6i8tHtsPjZNS jmron4grWnhoNMpM+jywIFjWyy0MT1WIDehP0GqzLIBgLODg1TIfGN1HMxBIxj5P yC9BRiGLNkIclOKknh0Yo2fj04XX38rETpeT7J3kbfRw8wzx5sTRgoIwwkkfoqjj GbcKSDmJmcm8OpCdl5xnMxdOxBv50p91j3VyBfOXzPeHw3sFzjURDSZgG16V5NY7 mrDzaHiRCFwdhN+k43zpyn8+A2JRI1dTz0yqGzJctyuCgFkkt4HEYLDafpeyEyg= =CK+x -END PGP SIGNATURE- xsa269.meta Description: Binary data xsa269.patch Description: Binary data xsa269-4.8.patch Description: Binary data xsa269-4.10.patch Description: Binary data xsa269-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 270 v2 - Linux netback driver OOB access in hash handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-270 version 2 Linux netback driver OOB access in hash handling UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Linux's netback driver allows frontends to control mapping of requests to request queues. When processing a request to set or change this mapping, some input validation was missing or flawed. IMPACT == A malicious or buggy frontend may cause the (usually privileged) backend to make out of bounds memory accesses, potentially resulting in one or more of privilege escalation, Denial of Service (DoS), or information leaks. VULNERABLE SYSTEMS == Linux kernel versions from 4.7 onwards are affected. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Felix Wilhelm of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa270.patch Linux 4.7 ... 4.17 $ sha256sum xsa270* 392868c37c1fe0d16c36086208fd0fc045c1baf8ab9b207995bce72681cb8c54 xsa270.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- Version: GnuPG v1 iQEcBAEBCAAGBQJbcw6uAAoJEIP+FMlX6CvZjxgH/iUkqOm+3T+Mr51itOmeOThy J10GbMvqyI8kb7oTVsfHRTMU/zCm01FSCb94B9WXxrKyr3J2RCWygZpS5D5+ujkK w8Ec3tqfRiJ6wXm+SUh+cFeiJBc4BUbTrSgc6VdtNqXO+uGB65CGVqFXTOZfSGMH AJKXQYOYe0gLtGU+H1TrCut6IC5RQKkdbI+gCEgahgc9HnPJnOrJZYoDaXsYCt1l gFPkd1UcVvtGbn+SUjNpXJlpWH8dY2tPeueqgu9LicGZ8jZkGI8FMCfOQ0g9dFMz t0Q8op8N3UAVXsPws+WvbGMuZ9mF71y9y8JUZYKRdg2iLND3CRO+asaMfN+3LSk= =gqkS -END PGP SIGNATURE- xsa270.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 273 v1 (CVE-2018-3620, CVE-2018-3646) - L1 Terminal Fault speculative side channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-3620,CVE-2018-3646 / XSA-273 L1 Terminal Fault speculative side channel ISSUE DESCRIPTION = In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts due to the page being not present (e.g. paged out to disk), or because of reserved bits being set. Architecturally, such a memory access will result in a page fault exception, but some processors will speculatively compute the physical address and issue an L1D lookup. If data resides in the L1D cache, it may be forwarded to dependent instructions, and may be leaked via a side channel. Furthermore: * SGX protections are not applied * EPT guest to host translations are not applied * SMM protections are not applied This issue is split into multiple CVEs depending on circumstance. The CVEs which apply to Xen are: * CVE-2018-3620 - Operating Systems and SMM * CVE-2018-3646 - Hypervisors For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html IMPACT == An attacker can potentially read arbitrary host RAM. This includes data belonging to Xen, data belonging to other guests, and data belonging to different security contexts within the same guest. An attacker could be a guest kernel (which can manipulate the pagetables directly), or could be guest userspace either directly (e.g. with mprotect() or similar system call) or indirectly (by gaming the guest kernel's paging subsystem). VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not known to be affected. Only Intel Core based processors (from at least Merom onwards) are potentially affected. Other processor designs (Intel Atom/Knights range), and other manufacturers (AMD) are not known to be affected. x86 PV guests fall into the CVE-2018-3620 (OS and SMM) category. x86 HVM and PVH guests fall into the CVE-2018-3646 (Hypervisors) category. MITIGATION == This issue can be mitigated with a combination of software and firmware changes. Switching guests to being HVM with shadow paging enabled (hap=0 in xl.cfg) is believed to mitigate the vulnerability on systems which don't have terabytes of RAM. However the performance impact of shadow paging in combination with in-guests Meltdown mitigations (KPTI, KVAS, etc) will most likely make this option prohibitive to use. RESOLUTION == New microcode, and possibly a new firmware image is required to prevent SMM data from being leaked with this vulnerability. Consult your hardware vendor. Software updates to Xen (details below) are required to prevent guests from being able to leak data belonging to Xen or to other guests in the system. Guest kernel software updates are required to prevent guest userspace from being able to leak data belonging to the kernel or other processes within the same guest. Consult your OS vendors. 1) For PV guests (which fall into the CVE-2018-3620 - OS/SMM case), leakage of data from Xen or other guests can be prevented entirely with software changes in Xen. If the PV guest tries to write an L1TF-vulnerable PTE (for current kernels, very likely when paging data out to disk), shadow paging is activated and forced upon the guest. Alternatively, if shadow paging is compiled out, the guest is crashed instead. Shadowing comes with a workload-dependent performance hit to the guest. Once the guest kernel software updates have been applied, a well behaved guest will not write vulnerable PTEs, and will therefore avoid the performance penalty (or crash) entirely. This behaviour is active by default for guests on affected hardware (controlled by `pv-l1tf=`), but is disabled by default for dom0. Dom0's exemption is because of instabilities when being shadowed, which are under investigation, but dom0 kernel updates should still be taken to mitigate the userspace aspect. 2) For HVM and PVH guests running with Hardware Assisted Paging (which fall into the CVE-2018-3646 - Hypervisors case), leakage of data from Xen or other guests can only be prevented entirely by disabling SMT/Hyper-threading (if available and active in the BIOS), and by using the L1D_FLUSH feature (available in the new microcode) on every VMEntry. On affected hardware, L1D_FLUSH is enabled by default (controlled by `spec-ctrl=[no-]l1d-flush`), subject to microcode availability. However, SMT/Hyper-threading is not disabled by default, because Xen does not have enough information to choose an appropriate default. Safety can be arranged in a number of ways by the toolstack, including with finer granularity than simply on or off. Therefore, users are expected to perform a risk assessment of their deployment, and explicitly chose a default (`smt=`). See the RISK ASSESSMENT section
[Xen-devel] Xen Security Advisory 274 v2 (CVE-2018-14678) - Linux: Uninitialized state in x86 PV failsafe callback path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-14678 / XSA-274 version 2 Linux: Uninitialized state in x86 PV failsafe callback path UPDATES IN VERSION 2 CVE assigned. Fix the title to refer to the failsafe callback path. ISSUE DESCRIPTION = Linux has a `failsafe` callback, invoked by Xen under certain conditions. Normally in this failsafe callback, error_entry is paired with error_exit; and error_entry uses %ebx to communicate to error_exit whether to use the user or kernel return path. Unfortunately, on 64-bit PV Xen on x86, error_exit is called without error_entry being called first, leaving %ebx with an invalid value. IMPACT == A rogue user-space program could crash a guest kernel. Privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Only 64-bit x86 PV Linux systems are vulnerable. All versions of Linux are vulnerable. MITIGATION == Switching to HVM or PVH guests will mitigate this issue. CREDITS === This issue was discovered by M. Vefa Bicakci, and recognized as a security issue by Andy Lutorminski. RESOLUTION == Applying the appropriate attached patch resolves this issue. NB this patch has not been accepted into Linux upstream yet. An updated advisory will be sent if the fix upstreamed looks significantly different. xsa274-linux-4.17.patch Linux 4.17 $ sha256sum xsa274* 0c30cb13d1d573f446c8cb8d4824ffad8ef9149a7589a19ef9bcc83c07bddcf5 xsa274-linux-4.17.patch $ NOTE ON THE LACK OF EMBARGO === The patch for this issue was published on linux-kernel without being first reported to the XenProject Security Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbYDYRAAoJEIP+FMlX6CvZo1gH/3+9TpyHsjwGIqIrK8wndAQ6 bth9m0e/Zq4alZflWRsQlJ64toE23dlZmFF9juHLPNEV/4jPm4CA1oRVLQQkJ3am 6kh4SQMNU5kDa/3S7sCnpYnM+IRg3JO9oDjKfz9PiDImKApzbE/NnGbQLP766BUD dCNKLdJlX+i3mRnKeqehFZKSPY43zOMU19hgfuKGEXwRCqlbLraL1+X5xGN11J51 iXHOJxK9fRBhi2d8jiCKAISqw0OMcROfrCgOFdabxYpw2/H49bjyADd0s9QV5piG In1b7S4AFEZfEzEQ0wlXs4wvhqmBZGdMyXxAL7BP4hTGXAJovLrfsL/nX/DXprQ= =H+Zn -END PGP SIGNATURE- xsa274-linux-4.17.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 274 - Linux: Uninitialized state in PV syscall return path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-274 Linux: Uninitialized state in PV syscall return path ISSUE DESCRIPTION = Linux has a `failsafe` callback, invoked by Xen under certain conditions. Normally in this failsafe callback, error_entry is paired with error_exit; and error_entry uses %ebx to communicate to error_exit whether to use the user or kernel return path. Unfortunately, on 64-bit PV Xen on x86, error_exit is called without error_entry being called first, leaving %ebx with an invalid value. IMPACT == A rogue user-space program could crash a guest kernel. Privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Only 64-bit x86 PV Linux systems are vulnerable. All versions of Linux are vulnerable. MITIGATION == Switching to HVM or PVH guests will mitigate this issue. CREDITS === This issue was discovered by M. Vefa Bicakci, and recognized as a security issue by Andy Lutorminski. RESOLUTION == Applying the appropriate attached patch resolves this issue. NB this patch has not been accepted into Linux upstream yet. An updated advisory will be sent if the fix upstreamed looks significantly different. xsa274-linux-4.17.patch Linux 4.17 $ sha256sum xsa274* 0c30cb13d1d573f446c8cb8d4824ffad8ef9149a7589a19ef9bcc83c07bddcf5 xsa274-linux-4.17.patch $ NOTE ON THE LACK OF EMBARGO === The patch for this issue was published on linux-kernel without being first reported to the XenProject Security Team. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAltYp7EMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZipwIAINGjP6d5vABI2CEdbromimlXiwGvTUBWOoIsvu1 bfLyeab334UBIpmouz+UhgKXFdujIFNpWqGpCc68xoNSsJiY+95GykbkxfghxzkL GQXzGloJVrHSzRGT+wUlTg9qCpbj1YVr1YtnACa34eXJTGhUBnOl0L3gBRbrjILb esECY3/EAKcnB8z1d2AzCRamYVGvfMO8xcolYrP1DzlNYQPnfrKvZu/7vkiyhbrO M9nM6+9MdS63JPGp5dX8xRO3TzyRDpgpSpkoMY8Lqhrr5/oLC9dhtdm/yK2kNtJ/ JluBn6q+EfZKoW/UcwTsehiTOOTKb/WYhC3e1jsRpm/+drU= =7MDt -END PGP SIGNATURE- xsa274-linux-4.17.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 266 (CVE-2018-12892) - libxl fails to honour readonly flag on HVM emulated SCSI disks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-12892 / XSA-266
version 3
libxl fails to honour readonly flag on HVM emulated SCSI disks
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
libxl fails to pass the readonly flag to qemu when setting up a SCSI
disk, due to what was probably an erroneous merge conflict resolution.
IMPACT
==
Malicious guest administrators or (in some situations) users may be
able to write to supposedly read-only disk images.
VULNERABLE SYSTEMS
==
Only emulated SCSI disks (specified as "sd" in the libxl disk
configuration, or an equivalent) are affected. IDE disks ("hd") are
not affected (because attempts to make them readonly are rejected).
Additionally, CDROM devices (that is, devices specified to be
presented to the guest as CDROMs, regardless of the nature of the
backing storage on the host) are not affected; they are always
readonly.
Only systems using qemu-xen (rather than qemu-xen-traditional) as the
device model version are vulnerable.
Only systems using libxl or libxl-based toolstacks are vulnerable.
(This includes xl, and libvirt with the libxl driver.)
The vulnerability is present in Xen versions 4.7 and later.
(In earlier versions, provided that the patch for XSA-142 has been
applied, attempts to create readonly disks are rejected.)
If the host and guest together usually support PVHVM, the issue is
exploitable only if the malicious guest administrator has control of
the guest kernel or guest kernel command line.
MITIGATION
==
Switching to qemu-xen-traditional will avoid this vulnerability.
This can be done with
device_model_version="qemu-xen-traditional"
in the xl configuration file.
Using stub domain device models (which necessarily involves switching
to qemu-xen-traditional) will also avoid this vulnerability.
This can be done with
device_model_stubdomain_override=true
in the xl configuration file.
All of these mitigations are liable to have other guest-visible
effects or even regressions.
It may be possible, depending on the configuration, to make the
underlying storage object readonly, or to make it reject writes.
CREDITS
===
This issue was discovered by Andrew Reimers of OrionVM.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa266/*.patch xen-unstable
xsa266-4.10/*.patch Xen 4.10.x
xsa266-4.9/*.patch Xen 4.9.x
xsa266-4.8/*.patch Xen 4.8.x
xsa266-4.7/*.patch Xen 4.7.x
xsa266-4.6/*.patch Xen 4.6.x
$ sha256sum xsa266* xsa266*/*
d0d998bb3c2f36b0795cdf86d52aa2da3eee72218f9073f398fc6fd2cf5719cd xsa266.meta
0e5634c9b730e2e022bfef9ded2bb81b7740d05911dae6499671db5cb90663c0
xsa266-4.7/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
e6dcef1bdd890a245cb9181266fc1378d77b08cf06c063f35a0835ab3b99cf91
xsa266-4.7/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
19ce6f236702219eb4831ed597f82dc81122fd517131e826643cee95b53d9f1c
xsa266-4.8/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
e0a4c616218bc42abada75aa5fa0c3e35da6b6334fe50d6104a5892ffebcdb04
xsa266-4.8/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
9fd48f20da140731bb71dde07035b938cf0966339449a0b6833787767c588c0a
xsa266-4.9/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
f23d0e76f15b1f6af487adc36a84cf2591197548ca7cab8ee84be72a87424cf7
xsa266-4.9/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
3d857f38d11b5531a651a45c2f151ac1493260524d4f49ead6833b5f1d599e64
xsa266-4.10/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
e380976abd77b5b46d69c9564aca3acf9bf467b36645ac34e035aba89d081591
xsa266-4.10/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
160dc8c8a918cae7259c252af098206f9eff357e52bdfc0b15553e9c31c587e6
xsa266/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch
2b44fd6baac094c82145667a16d9b1530b97fa342d0e635c831425b53a336266
xsa266/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of patches or mitigations 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 all of the patches and mitigations make significant
guest-visible changes. In particular, applying the patch will cause
the emulated SCSI disk object to be reported to the guest as readonly,
when previously it was reported as writeable.
Deployment is permitted only AFTER the embargo ends.
(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
[Xen-devel] Xen Security Advisory 265 (CVE-2018-12893) - x86: #DB exception safety check can be triggered by a guest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-12893 / XSA-265 version 3 x86: #DB exception safety check can be triggered by a guest UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = One of the fixes in XSA-260 added some safety checks to help prevent Xen livelocking with debug exceptions. Unfortunately, due to an oversight, at least one of these safety checks can be triggered by a guest. IMPACT == A malicious PV guest can crash Xen, leading to a Denial of Service. VULNERABLE SYSTEMS == All Xen systems which have applied the XSA-260 fix 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. An attacker needs to be able to control hardware debugging facilities to exploit the vulnerability, but such permissions are typically available to unprivileged users. MITIGATION == Running only x86 HVM or PVH guests will avoid the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa265.patch xen-unstable, Xen 4.10.x, 4.9.x, 4.8.x xsa265-4.7.patch Xen 4.7.x, 4.6.x $ sha256sum xsa265* 3eb66ed7251dcc4259eeffe608b2747857e269307d894a1cb950973420184aa7 xsa265.patch 00faf2a4159698b6540565ece06de103c3547855e2084324ca44772b8a24aa18 xsa265-4.7.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- Version: GnuPG v1 iQEcBAEBCAAGBQJbM+5JAAoJEIP+FMlX6CvZtSgIAMF8d/3Jor6b0EbW55JSLh76 56I8QfkqX4Xv/yWri3sXGJmPz7Af/qjDO+Ix5IScq54ugN5C8z7OBcbXFpX1WxNJ xCv6QjsbPmGCZHsT+NdWrl/ac6ZH3xlhE+S1awQ+9SkC+r6bRH/iROO+4DhpYQde CGoyYIwFq2VJoovh8lWHMsVl8VUXisyDk3bPK17VlAEFF1LuOkaan1UGEKRsciGX 12IlNw/I6c8a85wWpFtph1AOVZfrodWdwyj8vgLY3MHnEs+86/cm5O4+GxKHezHf P5dJDZ38HBPRL1qC+yFRV2sLxLgrc7fYlSWr3/xtOGo23aDLjCvS+FsMfIpyjPQ= =sf+j -END PGP SIGNATURE- xsa265.patch Description: Binary data xsa265-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 264 (CVE-2018-12891) - preemption checks bypassed in x86 PV MM handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-12891 / XSA-264 version 3 preemption checks bypassed in x86 PV MM handling UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Certain PV MMU operations may take a long time to process. For that reason Xen explicitly checks for the need to preempt the current vCPU at certain points. A few rarely taken code paths did bypass such checks. By suitably enforcing the conditions through its own page table contents, a malicious guest may cause such bypasses to be used for an unbounded number of iterations. IMPACT == A malicious or buggy PV guest may cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. VULNERABLE SYSTEMS == All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are vulnerable to an even wider class of attacks, due to them lacking preemption checks altogether in the affected code paths. Only x86 systems are affected. ARM systems are not affected. Only multi-vCPU x86 PV guests can leverage the vulnerability. x86 HVM or PVH guests as well as x86 single-vCPU PV ones cannot leverage the vulnerability. MITIGATION == Running only HVM, PVH, or single-vCPU PV guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator 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. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa264.patch xen-unstable xsa264-4.10.patch Xen 4.10.x ... 4.6.x $ sha256sum xsa264* a7d2edf219af3375ac0d49bff9e64628c70e704fcf131ea21684694517aa9210 xsa264.patch 66aca234b168abc01f28fe131b7e07645a73fd5d0f1d141d68343f31914d96cc xsa264-4.10.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- Version: GnuPG v1 iQEcBAEBCAAGBQJbM+5GAAoJEIP+FMlX6CvZy7cIALkEoEQnHw5O8vYC5KpDA24X P320Gh0OppT2qtQfKtAF7MaCc7VF9Tnhf3CrtNtolXMryM4vrh7KyOn8wk7jbRBy tp28e6ppO8ons9x1kBAmAZrno8LXwOa2t22hQpUv1mYksRkZotViAXS72t4HkOVl SEQVVLElWAIfPbGJwtu1/qgS8dCckA2MeLeN/dKHRm8gD63XsYt37nQnBa2iraKX yN5sdih+WLgXCf55mubFlQfE6+7qgn27khZpMeJAwGk6N+Rz/Q3q1zSFX9YB+P6d 9ppgoRFVxYpekwtCrLkVLxSAoEwCKi6sdYFnvIngHIMlLiVHjNsLd5YKTAsZcEE= =zTq5 -END PGP SIGNATURE- xsa264.patch Description: Binary data xsa264-4.10.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 262 (CVE-2018-10981) - qemu may drive Xen into unbounded loop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-10981 / XSA-262 version 3 qemu may drive Xen into unbounded loop UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = When Xen sends requests to a device model, the next expected action inside Xen is tracked using a state field. The requests themselves are placed in a memory page shared with the device model, so that the device model can communicate to Xen its progress on the request. The state field is in the request itself, where the device model may write to it. Xen correctly rejects invalid state values, but failed to reject invalid transitions between states. As a result, a device model which switches a request between two states at the right times can drive Xen into an unbounded loop. IMPACT == A malicious unprivileged device model can cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only HVM guests can expose this vulnerability. PV and PVH guests cannot expose this vulnerability, but note that the domains being able to leverage the vulnerability are PV or PVH ones, running the device model. This vulnerability is only applicable to Xen systems using stub domains. MITIGATION == Running only PV or PVH guests will avoid this issue. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa262.patch xen-unstable xsa262-4.10.patch Xen 4.10.x xsa262-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa262-4.6.patch Xen 4.6.x $ sha256sum xsa262* a5a3458c5efdad282bd769fcab2b94ebfe0a979befae3b4703201fcbf0970cc7 xsa262.meta 5aa73753d3eec8ae391b1364c430df7517bf4bdb3e65a8e6e8431898348f4ad9 xsa262.patch 7196b468b916bf956f8dc0cab20a5c29f8a1bfa4de4e4fa982b7b9c8494e4c0d xsa262-4.6.patch ec2b6ba9ed1d5e97fed4b54767160a75fe19d67e4519f716739bebdb78816191 xsa262-4.9.patch 91d3b329131b6d434b268c0c55fd4900033fce8b2582bd9278ae967efc980fb0 xsa262-4.10.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- Version: GnuPG v1 iQEcBAEBCAAGBQJa9Wy3AAoJEIP+FMlX6CvZh44IAK64kxWtVcMGLiTWU7NgsXub Y2+Hku8lXyVwqQ5smkIVPjG0AanXpgbB/c6uhtf53l8F2YjauEt/nG0QBkvLExmw DmusWb0Utmn4wIjBtBBv6holEHAxYZxL9qKrux2rnJXY8Yxf9hFsOWQsgx4RxsUR TAf9MVjzOWV5P7t1pvLfEA41cUQNWCML+Kog+bBptGvvuZ2AO5jS9qBmUAMCSQRH WUD4uZKI5xLtbYTDftqRqi6baEo4TIL6MrUHd8DAW7qR11gaRupDXG4w4W1mX9LM GMLrJJkk7U5jZ1as1WfJza2YA0zKaVJtScYdjYb/+g4XwbHrxAbqWOUOLAf9YrE= =ASkj -END PGP SIGNATURE- xsa262.meta Description: Binary data xsa262.patch Description: Binary data xsa262-4.6.patch Description: Binary data xsa262-4.9.patch Description: Binary data xsa262-4.10.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 261 (CVE-2018-10982) - x86 vHPET interrupt injection errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-10982 / XSA-261 version 3 x86 vHPET interrupt injection errors UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The High Precision Event Timer (HPET) can be configured to deliver interrupts in one of three different modes - through legacy interrupts; through the IO-APIC; or optionally via a method similar to PCI MSI. The last mode is optional and not implemented by Xen. However, of the first two modes, only the legacy variant was properly implemented. If a guest set up an HPET timer in IO-APIC mode, Xen would still handle this using the code for the legacy mode. Unfortunately, the available IO-APIC mode interrupt numbers are higher than legacy mode interrupts. The result was array overruns. IMPACT == A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. Privilege escalation, or information leaks, cannot be excluded. VULNERABLE SYSTEMS == Xen versions 3.4 and later are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 HVM guests can exploit the vulnerability. x86 PV and PVH guests cannot exploit the vulnerability. Only x86 HVM guests provided with hypervisor-side HPET emulation can exploit the vulnerability. That is the default configuration. x86 HVM guests whose configuration explicitly disables this emulation (via "hpet=0") cannot exploit the vulnerability. MITIGATION == Running only PV or PVH guests avoids the vulnerability. Not exposing the hypervisor based HPET emulation to HVM guests, by adding "hpet=0" to the guest configuration, also avoids the vulnerability. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa261.patch xen-unstable, Xen 4.10.x xsa261-4.9.patch Xen 4.9.x xsa261-4.8.patch Xen 4.8.x xsa261-4.7.patch Xen 4.7.x, Xen 4.6.x $ sha256sum xsa261* 7b7bbf0fb497491911816e522902f72d3b41355ba71455ab82ebf980160d1a1f xsa261.meta 175501977204db84d08a6fd81d9fd4b69f97f70cbf6f65e6ce0abfeab03eae95 xsa261.patch 98fb28bac871aae7c2f897a5506a2b03f340bf122a3a7f65aa65f3b3c9a525b4 xsa261-4.7.patch 503f1476813e6572dc37b5a0df65b5390567230d9cc006752bf72bf57bbd754d xsa261-4.8.patch f1aac841327d3b5b1e2007b4ebe56223de488e1eb2fa636653725d7d7cd5f82a xsa261-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) and the PV/PVH guest mitigation are permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER deployment of the "hpet=0" guest config 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- Version: GnuPG v1 iQEcBAEBCAAGBQJa9Wy1AAoJEIP+FMlX6CvZaxkIALwHLRw4JlORTplsS9bwnioh kuNausNp1pU9IqfcUKEI17n5+HekiXfLNennHEWYgYfdpNlWAbjUW5GaczII0KmS IJa8UvptnYydhg73Q8WWlYOx3i8nS15+ioIH8RIa1Vtvv0p7vbHf8C9BmjmYf1oa 5WH9Ut4Sx5wwALuCh/gO71ja5vgAAIpgQTf5R4KL0x9sJiCLTw2A4yxVmVd24bES 1fNoH3/qdbjgMjl7sLPCdsXLOqg9Xi77i5f5XnJMZgWQRQyh0XLeo5itiDIuMF/k tEMuEpKQ5+t4GNg92B67dFVWxeX1VIRrQ9a18WfXcwttM3xLFNcqt3BpSV9K8Tg= =KeNf -END PGP SIGNATURE- xsa261.meta Description: Binary data xsa261.patch Description: Binary data xsa261-4.7.patch Description: Binary data xsa261-4.8.patch Description: Binary data xsa261-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 260 (CVE-2018-8897) - x86: mishandling of debug exceptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-8897 / XSA-260 version 2 x86: mishandling of debug exceptions UPDATES IN VERSION 2 Public release. Updated .meta file ISSUE DESCRIPTION = When switching stacks, it is critical to have a matching stack segment and stack pointer. To allow an atomic update from what would otherwise be two adjacent instructions, an update which changes the stack segment (either a mov or pop instruction with %ss encoded as the destination register) sets the movss shadow for one instruction. The exact behaviour of the movss shadow is poorly understood. In practice, a movss shadow delays some debug exceptions (e.g. from a hardware breakpoint) until the subsequent instruction has completed. If the subsequent instruction normally transitions to supervisor mode (e.g. a system call), then the debug exception will be taken after the transition to ring0 is completed. For most transitions to supervisor mode, this only confuses Xen into printing a lot of debugging information. For the syscall instruction however, the exception gets taken before the syscall handler can move off the guest stack. IMPACT == A malicious PV guest 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. An attacker needs to be able to control hardware debugging facilities to exploit the vulnerability, but such permissions are typically available to unprivileged users. MITIGATION == Running only HVM or PVH guests avoids the vulnerability. Note however that a compromised device model (running in dom0 or a stub domain) can carry out this attack, so users with HVM domains are also advised to patch their systems. CREDITS === This issue was discovered by Andy Lutomirski, and Nick Peterson of Everdox Tech LLC. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa260-unstable/*.patch xen-unstable xsa260-4.10/*.patch Xen 4.10.x xsa260-4.9/*.patch Xen 4.9.x xsa260-4.8/*.patch Xen 4.8.x xsa260-4.7/*.patch Xen 4.7.x xsa260-4.6/*.patch Xen 4.6.x $ sha256sum xsa260* xsa260*/* f436009ea6d6a30cf9c316e909dcd260c223264884d2e4fc5b74bdaf2e515815 xsa260.meta 0f7e3cfecc59986fc950694bba7bb31ee9680b2390920335d6853fdf83ded9ef xsa260-unstable/xsa260-1.patch 4df5b9d05a8f02754b1e819b8cad35b3da9ba7fcdaee0fc762d572481ef69f93 xsa260-unstable/xsa260-2.patch 5c3f9cbc777ed7a93a97a4665e0188e1b1a05dd057da830203e018c73e9e5ce7 xsa260-unstable/xsa260-3.patch 4b280ec02418f30f0576e84f23ae565acee4fcc2d398b3828c1e12d9346583af xsa260-unstable/xsa260-4.patch 2c5ce2851351a40df9ed17fae3c6f7505dcda60209945321b545b6b6e4f065cb xsa260-4.6/xsa260-1.patch bfa2eb161f570b0295464ef41fc5add52e10853a1ec81de107f1a9deb945982f xsa260-4.6/xsa260-2.patch 2f30c4fbebeb77da50caff62a0f28d3afe8993bee19233543170f1955cebdcbc xsa260-4.6/xsa260-3.patch 363af89377d5819ad1450c8806824707d3e15700c179129aed62128e62ab1a0e xsa260-4.6/xsa260-4.patch 0c2552a36737975f4f46d7054b49fd018b68c302cef3b39b27c2f17cc60eb531 xsa260-4.7/xsa260-1.patch a92ef233a83923d6a18d51528ff28630ae3f1134ee76f2347397e22da9c84c24 xsa260-4.7/xsa260-2.patch 8469af8ba5b6722738b27c328eccc1d341af49c2e2bb23fe7b327a3349267b0e xsa260-4.7/xsa260-3.patch 0327c2ef7984a4aa000849c68a01181fdb01962637e78629c6fb34bb95414a74 xsa260-4.7/xsa260-4.patch a9be346f111bca3faf98045c089638ba960f291eb9ace03e8922d7b4f8a9b37e xsa260-4.8/xsa260-1.patch 740c0ee49936430fdf66ae8b75f9f51fe728c71a7c7a56667f845aea7669d344 xsa260-4.8/xsa260-2.patch 94dbb7ad7d409f9170950162904247c7cf0e360cec2a0a1f1a6653ce9ca43283 xsa260-4.8/xsa260-3.patch db440d76685cf1e8c332aea2aa13e6be43b1b7f68d9225dfe99bb2ee12e18b9e xsa260-4.8/xsa260-4.patch 11b55f664a4043ed3a79d3e1a07877c68c8c19df6112feffdac1e55547f0002e xsa260-4.9/xsa260-1.patch 38a762f8cf8db763d70f1ef35a4c2cac23282b694527a97b2eaf100a14f767eb xsa260-4.9/xsa260-2.patch 18d9ffd273bdbd070e1b613e7f18ed21cdb874dba5f7964e14bb4a3dbc8844ec xsa260-4.9/xsa260-3.patch c3d689d581c2ce6beaaa9d955f159a3b5da8007a24a08969b0953e89491f15a5 xsa260-4.9/xsa260-4.patch ffac7ab75bf65f8286b37d21cb4a4401d898670a4e52af88d8202ce4fe66edef xsa260-4.10/xsa260-1.patch fe85832a9b5b1076b3a9bdbd28a2f3be57cd019d66a725ce64698b1bd74145a8 xsa260-4.10/xsa260-2.patch 1955aed73828e23da871ef10e5ec49670ce59bdd06af2772e978f8e817e0319f xsa260-4.10/xsa260-3.patch 8f504f8fcf100f8a00bece9c4df8b8933dceeaf29b50492317f9cbf74aaf4aa4 xsa260-4.10/xsa260-4.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
[Xen-devel] Xen Security Advisory 262 - qemu may drive Xen into unbounded loop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-262 version 2 qemu may drive Xen into unbounded loop UPDATES IN VERSION 2 Public release. Updated .meta file ISSUE DESCRIPTION = When Xen sends requests to a device model, the next expected action inside Xen is tracked using a state field. The requests themselves are placed in a memory page shared with the device model, so that the device model can communicate to Xen its progress on the request. The state field is in the request itself, where the device model may write to it. Xen correctly rejects invalid state values, but failed to reject invalid transitions between states. As a result, a device model which switches a request between two states at the right times can drive Xen into an unbounded loop. IMPACT == A malicious unprivileged device model can cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only HVM guests can expose this vulnerability. PV and PVH guests cannot expose this vulnerability, but note that the domains being able to leverage the vulnerability are PV or PVH ones, running the device model. This vulnerability is only applicable to Xen systems using stub domains. MITIGATION == Running only PV or PVH guests will avoid this issue. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa262.patch xen-unstable xsa262-4.10.patch Xen 4.10.x xsa262-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa262-4.6.patch Xen 4.6.x $ sha256sum xsa262* a5a3458c5efdad282bd769fcab2b94ebfe0a979befae3b4703201fcbf0970cc7 xsa262.meta 5aa73753d3eec8ae391b1364c430df7517bf4bdb3e65a8e6e8431898348f4ad9 xsa262.patch 7196b468b916bf956f8dc0cab20a5c29f8a1bfa4de4e4fa982b7b9c8494e4c0d xsa262-4.6.patch ec2b6ba9ed1d5e97fed4b54767160a75fe19d67e4519f716739bebdb78816191 xsa262-4.9.patch 91d3b329131b6d434b268c0c55fd4900033fce8b2582bd9278ae967efc980fb0 xsa262-4.10.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- Version: GnuPG v1 iQEcBAEBCAAGBQJa8dQhAAoJEIP+FMlX6CvZyCUH/1eCZrElPEOUySjMRbix0EJ8 TW5pWx76PX27Hek4fk+tFxsfDWEqWN4AP9YgjSQKNyXUWEr1oiyq83Vq/JXM6bHt HSWbrh7sjkkziEGqlOXpryS8/RIE3CZC5nQOTAsPX65tB+2nXkOY5zwuxXM8Ivn6 9p0yitSWd3Ve68PLAhthb/7BDdsAgITtgtxuTDHmDB6h32Fo8m990nD1jbAcP9WR q32gqXUMdlCf161/viPkSnrRqsnmdzPbXDsAzqtnUeVGNtqb5mI8jqox9Z6JGedG qMwlZVWO7TzcpO/18KbI8qYypL2/ensEo4bPbvRN7qzA6y8QGwMrLsygtZuBVkw= =D72A -END PGP SIGNATURE- xsa262.meta Description: Binary data xsa262.patch Description: Binary data xsa262-4.6.patch Description: Binary data xsa262-4.9.patch Description: Binary data xsa262-4.10.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 261 - x86 vHPET interrupt injection errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-261 version 2 x86 vHPET interrupt injection errors UPDATES IN VERSION 2 Versions 3.1 ... 3.3 don't appear to be vulnerable. Public release. Updated .meta file ISSUE DESCRIPTION = The High Precision Event Timer (HPET) can be configured to deliver interrupts in one of three different modes - through legacy interrupts; through the IO-APIC; or optionally via a method similar to PCI MSI. The last mode is optional and not implemented by Xen. However, of the first two modes, only the legacy variant was properly implemented. If a guest set up an HPET timer in IO-APIC mode, Xen would still handle this using the code for the legacy mode. Unfortunately, the available IO-APIC mode interrupt numbers are higher than legacy mode interrupts. The result was array overruns. IMPACT == A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. Privilege escalation, or information leaks, cannot be excluded. VULNERABLE SYSTEMS == Xen versions 3.4 and later are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 HVM guests can exploit the vulnerability. x86 PV and PVH guests cannot exploit the vulnerability. Only x86 HVM guests provided with hypervisor-side HPET emulation can exploit the vulnerability. That is the default configuration. x86 HVM guests whose configuration explicitly disables this emulation (via "hpet=0") cannot exploit the vulnerability. MITIGATION == Running only PV or PVH guests avoids the vulnerability. Not exposing the hypervisor based HPET emulation to HVM guests, by adding "hpet=0" to the guest configuration, also avoids the vulnerability. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa261.patch xen-unstable, Xen 4.10.x xsa261-4.9.patch Xen 4.9.x xsa261-4.8.patch Xen 4.8.x xsa261-4.7.patch Xen 4.7.x, Xen 4.6.x $ sha256sum xsa261* 7b7bbf0fb497491911816e522902f72d3b41355ba71455ab82ebf980160d1a1f xsa261.meta 175501977204db84d08a6fd81d9fd4b69f97f70cbf6f65e6ce0abfeab03eae95 xsa261.patch 98fb28bac871aae7c2f897a5506a2b03f340bf122a3a7f65aa65f3b3c9a525b4 xsa261-4.7.patch 503f1476813e6572dc37b5a0df65b5390567230d9cc006752bf72bf57bbd754d xsa261-4.8.patch f1aac841327d3b5b1e2007b4ebe56223de488e1eb2fa636653725d7d7cd5f82a xsa261-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) and the PV/PVH guest mitigation are permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER deployment of the "hpet=0" guest config 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- Version: GnuPG v1 iQEcBAEBCAAGBQJa8dQgAAoJEIP+FMlX6CvZZ54IAIlcZ6vu0mYvjwL8I23QbbtW 8uDzgozK9S8r2tPXxn6gbqSwFACuKeS61hnhw7v3gNEClpSQip+dHlGS6ME3AUVZ m0Vtn6eDQXHiwW+9jM4/j8gxLAqgfxUUpTuR74tZxh0kMmXKShirt+ob+9ptxfB7 nu8QiEVDH87P7JnDUXn1czNBRuD3KP0cmsAW/7VaOUm5R/+1RwYX6df9rEN6TU/+ LWMrBeepU8mh8oRgA5yJ78iiCB6KUfURsz1JuPmNd49rSTVK2WGFAH5vNz7EjRyU kbVAJgjWYGGFo0BTXSt8kCi0pdlGEHRh3+KIIuvAxm+JfQtrFC0K8lpzQcpTPYY= =jUil -END PGP SIGNATURE- xsa261.meta Description: Binary data xsa261.patch Description: Binary data xsa261-4.7.patch Description: Binary data xsa261-4.8.patch Description: Binary data xsa261-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 259 (CVE-2018-10471) - x86: PV guest may crash Xen with XPTI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-10471 / XSA-259 version 3 x86: PV guest may crash Xen with XPTI UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The workaround for the Meltdown vulnerability (XSA-254) failed to deal with an error code path connecting the INT 80 handling with general exception handling. This results in an unconditional write attempt of the value zero to an address near 2^64, in cases where a PV guest has no handler installed for INT 80 on one of its vCPU-s. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions which the XSA-254 fixes were applied to are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH and HVM guests cannot exploit the vulnerability. MITIGATION == Running only PVH or HVM guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa259.patch xen-unstable, Xen 4.10.x ... xen 4.7.x xsa259-4.6.patch Xen 4.6.x $ sha256sum xsa259* 5c14a90af066c952974324b361e2a428c280f876b854f0c85a78e8579054a4d1 xsa259.meta ff2efb5eb2502ded988d0aa15351030a15494a9e2223eafbb88377a8e4d39dcb xsa259.patch c40bc8802077cf73f8393fb50574b7c7efbc4d127e202b0ebd757d34aa07aac3 xsa259-4.6.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- Version: GnuPG v1 iQEcBAEBCAAGBQJa5xa0AAoJEIP+FMlX6CvZDGEIAL5KbzcBUVjNsguU0HQ2Q6k8 WejwrXdKkncObK3yoxuybDE4NS+A5o0FbhdpJ86ukemZd2pMutgz79Z14UhSiURk Owdj7BlzD64O42OftKqXiNKVp4QhOlOh02TU08Q4m6GKAtCi+HlBcK8EQFR8URhX E2zLtpqGv5z6qx26raTDWQAssak4qL/NPSQ7oc3Eqo7P7H8B3Jw+F7DoR9a1g2ye gwuINHuk0ea9+jLoinNTDDn17xDAwp8KHPGrI/ivlwGyFipBISICdReDHe/EfIWS BNvrZl4ccDe95B1SosN8d0/qGYPLfpSN910hmm0ZTit0XffDseLv/odxoLuDvuQ= =clOX -END PGP SIGNATURE- xsa259.meta Description: Binary data xsa259.patch Description: Binary data xsa259-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 258 (CVE-2018-10472) - Information leak via crafted user-supplied CDROM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-10472 / XSA-258 version 3 Information leak via crafted user-supplied CDROM UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = QEMU handles many different file formats for virtual disks (e.g., raw, qcow2, vhd, ). Some of these formats are "snapshots" that specify "patches" to an alternate disk image, whose filename is included in the snapshot file. When qemu is given a disk but the type is not specified, it attempts to guess the file format by reading it. If a disk image is intended to be 'raw', but the image is entirely controlled by an attacker, the attacker could write a header to the image, describing one of these "snapshot" formats, and pointing to an arbitrary file as the "backing" file. When attaching disks via command-line parameters at boot time (including both "normal" disks and CDROMs), libxl specifies the format; however, when inserting a CDROM live via QMP, the format was not specified. IMPACT == An attacker supplying a crafted CDROM image can read any file (or device node) on the dom0 filesystem with the permissions of the qemu devicemodel process. (The virtual CDROM device is read-only, so no data can be written.) VULNERABLE SYSTEMS == Only x86 HVM guests with a virtual CDROM device are affected. ARM guests, x86 PV guests, x86 PVH guests, and x86 HVM guests without a virtual CDROM device are not affected. Only systems with qemu running in dom0 are affected; systems running stub domains are not affected. Only systems using qemu-xen (aka "qemu-upstream" are affected; systems running qemu-xen-traditional are not affected. Only systems in which an attacker can provide a raw CDROM image, and cause that image to be virtually inserted while the guest is running, are affected. Systems which only have host administrator-supplied CDROM images, or systems which allow images to be added only at boot time, are not affected. MITIGATION == One workaround is to "wrap" the guest-supplied image in a specific format; i.e., accept a raw image from the untrusted user, and convert it into qcow2 format; for example: qemu-img convert -f raw -O qcow2 untrusted.raw wrapped.qcow2 WARNING: Make sure to specify `-f raw` if you do this, or qemu will "guess" the format of "untrusted.raw" (which the attacker may have crafted to look like a qcow2 snapshot image with an alternativee base). Another workaround is to allow guests to only change CDROMs at boot time, not while the guest is running. CREDITS === This issue was discovered by Anthony Perard of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa258.patch xen-unstable, Xen 4.10.x, Xen 4.9.x xsa258-4.8.patch Xen 4.8.x, Xen 4.7.x xsa258-4.6.patch Xen 4.6.x $ sha256sum xsa258* 2c35a77eeca5579b5c32517c5ba511c836fa70f8b824ca8883fc6e1a7e608405 xsa258.meta 7e8014deae4fa19464fe6570d0719f8f0d7730dd153d58b2fa38b0cd5ed2e459 xsa258.patch 2c58060a42dafbf65563941dd8c737732124b49eb47007cc60f647553227f557 xsa258-4.6.patch ebba2f1f084249cd1e1c2f59e338412161884c31c83dbba03fc1e10bf4ba57a1 xsa258-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or the "wrap" 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, deploying the "only allow guests to change CDROMs at boot time" 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 it may give attackers a hint of where to look for the vulnerability. Deployment of this mitigation is permitted only AFTER the embargo ends. Additionally, 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 iQEcBAEBCAAGBQJa5xaxAAoJEIP+FMlX6CvZYdgIAMiidM7VGBh2l+DUooYZjKm/ BQEzqlM7EMqq8IiK7lNSXrZIXdLiR8S4oNhRZlqv3m2zxjDmdpS1N2F/6Xt37qOv
[Xen-devel] Xen Security Advisory 259 - x86: PV guest may crash Xen with XPTI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-259 version 2 x86: PV guest may crash Xen with XPTI UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The workaround for the Meltdown vulnerability (XSA-254) failed to deal with an error code path connecting the INT 80 handling with general exception handling. This results in an unconditional write attempt of the value zero to an address near 2^64, in cases where a PV guest has no handler installed for INT 80 on one of its vCPU-s. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions which the XSA-254 fixes were applied to are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH and HVM guests cannot exploit the vulnerability. MITIGATION == Running only PVH or HVM guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa259.patch xen-unstable, Xen 4.10.x ... xen 4.7.x xsa259-4.6.patch Xen 4.6.x $ sha256sum xsa259* 5c14a90af066c952974324b361e2a428c280f876b854f0c85a78e8579054a4d1 xsa259.meta ff2efb5eb2502ded988d0aa15351030a15494a9e2223eafbb88377a8e4d39dcb xsa259.patch c40bc8802077cf73f8393fb50574b7c7efbc4d127e202b0ebd757d34aa07aac3 xsa259-4.6.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- Version: GnuPG v1 iQEcBAEBCAAGBQJa4G58AAoJEIP+FMlX6CvZrqIH+QFfC5NOoFhVZAChTU0WQ7U6 UwP7yEyLeY15VrGb4YvwzKhvTNwsRRiYTbTNB/QjAkrUkMRhBiUIz7mQqBl0Vc/N 4zblt+YNdDMjhCllTjvtYU6OJzbsqvEBByB4mFrz6fxfZiuXIbOnMUOxLHRRdXLR 6JR8+4RrheKNl9DF6lmLj50d3G/fKrNLY9id8VcDG1TGIB6E1CbJ6gibw7FiYDSq PETa5O1szo2FO2yY+xcMzzGLHv+oVeKZnmuq9KYtP7Q+G823Twz1RE6rTBEjwhs9 sDGUlgZ48QVfSzer10syzyeX0p9hLHyKhlJnCrmCiywvKq68/uVexZFNcOKRPtE= =n+01 -END PGP SIGNATURE- xsa259.meta Description: Binary data xsa259.patch Description: Binary data xsa259-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 258 - Information leak via crafted user-supplied CDROM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-258 version 2 Information leak via crafted user-supplied CDROM UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = QEMU handles many different file formats for virtual disks (e.g., raw, qcow2, vhd, ). Some of these formats are "snapshots" that specify "patches" to an alternate disk image, whose filename is included in the snapshot file. When qemu is given a disk but the type is not specified, it attempts to guess the file format by reading it. If a disk image is intended to be 'raw', but the image is entirely controlled by an attacker, the attacker could write a header to the image, describing one of these "snapshot" formats, and pointing to an arbitrary file as the "backing" file. When attaching disks via command-line parameters at boot time (including both "normal" disks and CDROMs), libxl specifies the format; however, when inserting a CDROM live via QMP, the format was not specified. IMPACT == An attacker supplying a crafted CDROM image can read any file (or device node) on the dom0 filesystem with the permissions of the qemu devicemodel process. (The virtual CDROM device is read-only, so no data can be written.) VULNERABLE SYSTEMS == Only x86 HVM guests with a virtual CDROM device are affected. ARM guests, x86 PV guests, x86 PVH guests, and x86 HVM guests without a virtual CDROM device are not affected. Only systems with qemu running in dom0 are affected; systems running stub domains are not affected. Only systems using qemu-xen (aka "qemu-upstream" are affected; systems running qemu-xen-traditional are not affected. Only systems in which an attacker can provide a raw CDROM image, and cause that image to be virtually inserted while the guest is running, are affected. Systems which only have host administrator-supplied CDROM images, or systems which allow images to be added only at boot time, are not affected. MITIGATION == One workaround is to "wrap" the guest-supplied image in a specific format; i.e., accept a raw image from the untrusted user, and convert it into qcow2 format; for example: qemu-img convert -f raw -O qcow2 untrusted.raw wrapped.qcow2 WARNING: Make sure to specify `-f raw` if you do this, or qemu will "guess" the format of "untrusted.raw" (which the attacker may have crafted to look like a qcow2 snapshot image with an alternativee base). Another workaround is to allow guests to only change CDROMs at boot time, not while the guest is running. CREDITS === This issue was discovered by Anthony Perard of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa258.patch xen-unstable, Xen 4.10.x, Xen 4.9.x xsa258-4.8.patch Xen 4.8.x, Xen 4.7.x xsa258-4.6.patch Xen 4.6.x $ sha256sum xsa258* 2c35a77eeca5579b5c32517c5ba511c836fa70f8b824ca8883fc6e1a7e608405 xsa258.meta 7e8014deae4fa19464fe6570d0719f8f0d7730dd153d58b2fa38b0cd5ed2e459 xsa258.patch 2c58060a42dafbf65563941dd8c737732124b49eb47007cc60f647553227f557 xsa258-4.6.patch ebba2f1f084249cd1e1c2f59e338412161884c31c83dbba03fc1e10bf4ba57a1 xsa258-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or the "wrap" 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, deploying the "only allow guests to change CDROMs at boot time" 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 it may give attackers a hint of where to look for the vulnerability. Deployment of this mitigation is permitted only AFTER the embargo ends. Additionally, 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 iQEcBAEBCAAGBQJa4G55AAoJEIP+FMlX6CvZHjYIAJEtdHT5yPyQuSjh8ATOYN/s DrpUSw65EvvgbuGJTcmWZMc335AvyoMDtYVtk+Ouy5dMlfuUXcwjimoLWC6FfEDg aJ19puvjVaA8JcRzimlWQjru8Eqyso1+uNjuvsv1RCSkhN6qGBGCx6xlyWJL0tGk
[Xen-devel] Xen Security Advisory 256 (CVE-2018-7542) - x86 PVH guest without LAPIC may DoS the host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-7542 / XSA-256 version 3 x86 PVH guest without LAPIC may DoS the host UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = So far, x86 PVH guests can be configured with or without Local APICs. Configurations with Local APICs are identical to x86 HVM guests, and will use as much hardware acceleration support as possible. Configurations without Local APICs try to turn off all hardware acceleration, and disable all software emulation. Multiple paths in Xen assume the presence of a Local APIC without sufficient checks, and can fall over a NULL pointer. On Intel hardware, the logic to turn off hardware acceleration is incomplete and leaves the guest with full control of the real Task Priority Register. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == Xen version 4.8 and onwards are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PVH guests can exploit the vulnerability. x86 PV and HVM guests cannot exploit the vulnerability. MITIGATION == Running only PV or HVM guests avoids the vulnerability. Running all PVH guests with "apic=1" in the guest configuration file (or equivalent thereof) also avoids the vulnerability. CREDITS === This issue was discovered by Ian Jackson of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa256.patch xen-unstable, Xen 4.10.x, Xen 4.9.x xsa256-4.8.patch Xen 4.8.x $ sha256sum xsa256* 3e45cc3f2ea516e7470083592041e238c0dfe32324790b2fba0e47c9efe38865 xsa256.patch c029fcb67ff7c3c9a2adcb8e6f5e245a0d347acc8a9b3530591a639cbf321349 xsa256-4.8.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- Version: GnuPG v1 iQEcBAEBCAAGBQJal/zVAAoJEIP+FMlX6CvZkSgIAJG8fezZnjklV1FlQpzIfy5Y qMg0PaUUg69vSmc1uxuM51pi/KATCE541VdJesZ7CviFvrNm46fj2OF4L5wGNbq7 wqi1Ywn3J8iVOkzVyhQbb0ZXzBQK0Z48Q7qcZNlnJ8Ci1MP8wjWK5Aq0BO7qUEpM oHawLRAmEY0JKxIWwlpvR35dwoGp3cOSy0yHSWrpuj+Q59rhOuY/hyn0NlMBjDqp CbJqLC1T0lfC9fpe7LRxDBusleZm/QGiWDHjFMS560koDt4gq6i8zTpVIJrpHdFF eGhKY4JhVJpNljOB0CD87qk9WpN8+jxb1hVigMfZcyMMNygPLH5Bnh5QfhZwd00= =JPu9 -END PGP SIGNATURE- xsa256.patch Description: Binary data xsa256-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 255 (CVE-2018-7541) - grant table v2 -> v1 transition may crash Xen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-7541 / XSA-255
version 4
grant table v2 -> v1 transition may crash Xen
UPDATES IN VERSION 4
CVE assigned.
ISSUE DESCRIPTION
=
Grant tables come in two flavors (versions), and domains are permitted
to freely change between them (subject to certain constraints). For
the guest to use the facility, both the "normal" shared pages
(applicable to v1 and v2) and the "status" pages (applicable to v2
only) need to be mapped by the guest into its address space.
When transitioning from v2 to v1, the status pages become unnecessary
and are therefore freed by Xen. That means Xen needs to check that
there are no mappings of those pages by the domain. However, that
check was mistakenly implemented as a bug check, rather than returning
an error to the guest.
IMPACT
==
A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host. Privilege
escalation as well as information leaks cannot be ruled out for HVM,
PVH (both x86), and ARM guests.
The impact is more severe for Xen versions 4.0.x, 4.1.0 ... 4.1.3, and
4.2 in that the pages are freed without any checking, thus allowing
their re-use for another domain, or by Xen itself, while there still
are active mappings (see XSA-26).
VULNERABLE SYSTEMS
==
Xen versions 4.0 and newer are vulnerable.
Both x86 and ARM systems are vulnerable.
MITIGATION
==
Using the "gnttab=max_ver:1" hypervisor command line option, where
available, to disable use of v2 grant tables allows to avoid the
vulnerability. Use of this option will, however, break any guests which
require to make use of v2 functionality. The patch introducing this
option was not merged so far, but is available (in its current form) at
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00059.html
("common/gnttab: Introduce command line feature controls").
There is no other known mitigation.
CREDITS
===
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa255-?.patch xen-unstable, Xen 4.10.x
xsa255-4.9-?.patch Xen 4.9.x, Xen 4.8.x
xsa255-4.7-?.patch Xen 4.7.x
xsa255-4.6-?.patch Xen 4.6.x
$ sha256sum xsa255*
05a5570ecf4354f7aad35bb77a4c2f5f556bcabf3555829a98c94dcfb6dd4696 xsa255-1.patch
df43a147f1e1a2b7d59588bc91cdaac05d4e45bcfc4e2c8cb5e8de840d44b43d xsa255-2.patch
be62d81583df10a6be275427d5cfa02084c8717473b3694cd2a9bbdc10cbadcb
xsa255-4.6-1.patch
3dd58114c5ce68fd8dd43f8f92eaafdcec1fd9add37eb41faed1cf818058539a
xsa255-4.6-2.patch
9bfc4a33a0faeb36aec8449ea940cef52d523cc3d13529b4eeaae64bf5a7b644
xsa255-4.7-1.patch
6d95ceb54298de7863dc7133c0f3adf85f7da9b8d326146ff46e641194a47fc0
xsa255-4.7-2.patch
0b4706f0d2d21d4f6414ae9c0205e553bfb792c23d44e129b3a0f90be557d13f
xsa255-4.9-1.patch
9c6b2d2183ffa484182ca75e1a048d0713c4d150e750ccf58be5a24991a3e1de
xsa255-4.9-2.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches 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 mitigation 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 this produces a guest-visible
change which will indicate which component contains the vulnerability.
Additionally, 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
iQEcBAEBCAAGBQJal/zSAAoJEIP+FMlX6CvZT6EH/1V/ZKiEzRRz7zdQtP29RKFJ
vlqhVO76d1jerdS19crtthQIP9y0hXBBZqLOcbkzH1JrSA9Zt6GrsvOBB/YTczzr
8pEBEapnlUbTr6zk0V6+maXtmIzmmMhUjy6qvdZIE3qs9gxS2ZQkAAFRJNP/mPNY
3saNnh1h66ojWmGZYq6Corb3bNbOEX51uKNsUP8f5jbPSNPV6iwgQ5ogM3HsI+LV
vibg2VVnlDlHP5Wf2Bzz7KQOUR+FH+4fyJoUJIK7nwWQikBp5Px7uvGBiNcwwUG6
fpEKB1QnrW1FVl9CkrqzcFJs2ChjFW9mORTflth5Ai7g86ZyEtVdhfJNav4mLmk=
=+53n
-END PGP SIGNATURE-
xsa255-1.patch
Description: Binary data
[Xen-devel] Xen Security Advisory 252 (CVE-2018-7540) - DoS via non-preemptable L3/L4 pagetable freeing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-7540 / XSA-252 version 3 DoS via non-preemptable L3/L4 pagetable freeing UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Guests have the ability to request removal of memory from themselves. This operation is intended to be requested for normal read/write pages, but is also permitted to be used on other types of pages. So far this in particular included pages pinned to their current type, with the necessary unpinning happening implicitly. The unpinning of higher level page tables can, however, take a significant amount of time, and hence is generally expected to be carried out with intermediate preemption checks. Such checks were missing from the code path involved here. IMPACT == A malicious guest administrator can cause a Denial of Service (DoS). Specifically, prevent use of a physical CPU for a significant period of time. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only PV guests can leverage this vulnerability. HVM guests cannot leverage this vulnerability. MITIGATION == Running only HVM guests will avoid this issue. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa252.patch xen-unstable, Xen 4.10.0 xsa252-4.9.patch Xen 4.9.x, Xen 4.8.x xsa252-4.7.patch Xen 4.7.x xsa252-4.6.patch Xen 4.6.x, Xen 4.5.x $ sha256sum xsa252* 5bf651378b92520969cde49d11500bcaeffab15590d21c16736be408a85ab3fa xsa252.meta 53174dfd05eb274431dc756c9c3a39b355d485d6c9d12a8797b350bab343d22e xsa252.patch b7ba005fa62ace07f4880cc79824968c24ead3182245e4ed3a6e22cf8d2d7c05 xsa252-4.6.patch 14f37eb6b7a9fb19b258ca3c0e2da71dbc4240e6273137d5eb4003b122101aa6 xsa252-4.7.patch cb679f2145e76b1c754c4377b397d201007f50438ee18e451c4b0da3f510a293 xsa252-4.9.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- Version: GnuPG v1 iQEcBAEBCAAGBQJal/zQAAoJEIP+FMlX6CvZKAAH+gKqf6lQicFUpzEGqbVbXTg9 DYm8S6nKvn5/tgcquznswDZ2EpEMN4j8NaII4it2UQSZo7jOn7FOxiewdhAHcIAf vW2MHz9tkE+DXPOod4tDwhjonzLo1n0uqVuoUylq8atIrX2KxcSDJAbRp78lmUoY rxklw0uOlpno4hAJ4BaNY+fvjDyPBksApstJ6CZ/BUhaJeebYHbkCo92CTUvcThg xdA/M+w62plLCpwdnAJY5YV8NP32I5FNTe0sPnpszfk+gyDTLBMDHXdr+yegGayt ZvcH5c/NEeqeeF+MSd6ibnVfboQilDoPCnf9iL5ISOHtajkR2TK2vToi2hWQsi4= =Bn7r -END PGP SIGNATURE- xsa252.meta Description: Binary data xsa252.patch Description: Binary data xsa252-4.6.patch Description: Binary data xsa252-4.7.patch Description: Binary data xsa252-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 255 - grant table v2 -> v1 transition may crash Xen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-255
version 3
grant table v2 -> v1 transition may crash Xen
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
Grant tables come in two flavors (versions), and domains are permitted
to freely change between them (subject to certain constraints). For
the guest to use the facility, both the "normal" shared pages
(applicable to v1 and v2) and the "status" pages (applicable to v2
only) need to be mapped by the guest into its address space.
When transitioning from v2 to v1, the status pages become unnecessary
and are therefore freed by Xen. That means Xen needs to check that
there are no mappings of those pages by the domain. However, that
check was mistakenly implemented as a bug check, rather than returning
an error to the guest.
IMPACT
==
A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host. Privilege
escalation as well as information leaks cannot be ruled out for HVM,
PVH (both x86), and ARM guests.
The impact is more severe for Xen versions 4.0.x, 4.1.0 ... 4.1.3, and
4.2 in that the pages are freed without any checking, thus allowing
their re-use for another domain, or by Xen itself, while there still
are active mappings (see XSA-26).
VULNERABLE SYSTEMS
==
Xen versions 4.0 and newer are vulnerable.
Both x86 and ARM systems are vulnerable.
MITIGATION
==
Using the "gnttab=max_ver:1" hypervisor command line option, where
available, to disable use of v2 grant tables allows to avoid the
vulnerability. Use of this option will, however, break any guests which
require to make use of v2 functionality. The patch introducing this
option was not merged so far, but is available (in its current form) at
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00059.html
("common/gnttab: Introduce command line feature controls").
There is no other known mitigation.
CREDITS
===
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa255-?.patch xen-unstable, Xen 4.10.x
xsa255-4.9-?.patch Xen 4.9.x, Xen 4.8.x
xsa255-4.7-?.patch Xen 4.7.x
xsa255-4.6-?.patch Xen 4.6.x
$ sha256sum xsa255*
05a5570ecf4354f7aad35bb77a4c2f5f556bcabf3555829a98c94dcfb6dd4696 xsa255-1.patch
df43a147f1e1a2b7d59588bc91cdaac05d4e45bcfc4e2c8cb5e8de840d44b43d xsa255-2.patch
be62d81583df10a6be275427d5cfa02084c8717473b3694cd2a9bbdc10cbadcb
xsa255-4.6-1.patch
3dd58114c5ce68fd8dd43f8f92eaafdcec1fd9add37eb41faed1cf818058539a
xsa255-4.6-2.patch
9bfc4a33a0faeb36aec8449ea940cef52d523cc3d13529b4eeaae64bf5a7b644
xsa255-4.7-1.patch
6d95ceb54298de7863dc7133c0f3adf85f7da9b8d326146ff46e641194a47fc0
xsa255-4.7-2.patch
0b4706f0d2d21d4f6414ae9c0205e553bfb792c23d44e129b3a0f90be557d13f
xsa255-4.9-1.patch
9c6b2d2183ffa484182ca75e1a048d0713c4d150e750ccf58be5a24991a3e1de
xsa255-4.9-2.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches 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 mitigation 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 this produces a guest-visible
change which will indicate which component contains the vulnerability.
Additionally, 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
iQEcBAEBCAAGBQJalUeyAAoJEIP+FMlX6CvZrgoH/3bGXBS8dUA/59slmiyw7UpG
jShI/y+aCo5APtvPVrm+1cM/YOFVCHoZcnL0V+E9VBekCeVo84lfrDwrsU76RWNq
vIyPKBBeJbJFCCLatiWWDSEG6MukhhF0xiJy5RuMd/A1d4+6XLsD3y2bIkBb1P13
WzPJcgN1/wMM4A5Tp7MgyncOdm5yODu0A85L4J6fOOGm+LrNErvFpREcivoIKhbq
PKm04dSNb3jp7b7J9cVfSH/ZhpD1szwJ9yrddX3zgOF/1jlDi54Bri2potAZRZ0j
h+dN4Oh1HUR6NJeTuJqHx/VwFsx7V2zmWZZwsHaI7f/Oe15GRY/vPJNEm3VhNoM=
=atsR
-END PGP SIGNATURE-
xsa255-1.patch
Description: Binary data
xsa255-2.patch
[Xen-devel] Xen Security Advisory 252 - DoS via non-preemptable L3/L4 pagetable freeing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-252 version 2 DoS via non-preemptable L3/L4 pagetable freeing UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Guests have the ability to request removal of memory from themselves. This operation is intended to be requested for normal read/write pages, but is also permitted to be used on other types of pages. So far this in particular included pages pinned to their current type, with the necessary unpinning happening implicitly. The unpinning of higher level page tables can, however, take a significant amount of time, and hence is generally expected to be carried out with intermediate preemption checks. Such checks were missing from the code path involved here. IMPACT == A malicious guest administrator can cause a Denial of Service (DoS). Specifically, prevent use of a physical CPU for a significant period of time. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only PV guests can leverage this vulnerability. HVM guests cannot leverage this vulnerability. MITIGATION == Running only HVM guests will avoid this issue. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa252.patch xen-unstable, Xen 4.10.0 xsa252-4.9.patch Xen 4.9.x, Xen 4.8.x xsa252-4.7.patch Xen 4.7.x xsa252-4.6.patch Xen 4.6.x, Xen 4.5.x $ sha256sum xsa252* 5bf651378b92520969cde49d11500bcaeffab15590d21c16736be408a85ab3fa xsa252.meta 53174dfd05eb274431dc756c9c3a39b355d485d6c9d12a8797b350bab343d22e xsa252.patch b7ba005fa62ace07f4880cc79824968c24ead3182245e4ed3a6e22cf8d2d7c05 xsa252-4.6.patch 14f37eb6b7a9fb19b258ca3c0e2da71dbc4240e6273137d5eb4003b122101aa6 xsa252-4.7.patch cb679f2145e76b1c754c4377b397d201007f50438ee18e451c4b0da3f510a293 xsa252-4.9.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- Version: GnuPG v1 iQEcBAEBCAAGBQJalUevAAoJEIP+FMlX6CvZaDEH/0MrInFkPbVr0OFNs8KHuZNh 5fz3sXFbf/7O0aTdFT5JJpwZaOngSyjnnKJKZMtsEHz52Nzs6o4xnYzqzNlemPJf FG5NKjWgQI762H8Co4z65eWwHevfDo9a1XAy2LRHlbaNkGXMwic3B2VbhW2A0Hkp nAATx19TpS21Fk4dK5+P8HCy+YN5RwPKKADE1Jps0MsCcSZ9NHcKfedokqpaD2DQ XEWlfhclzHGLdrBGFWtvBUGuxUIioB/ovVQK/6q7/Go2nLNvkrU63tdiCchzpVLA qXskJeatqqH/QnLXxhgzAQWf4rmjCU21l3Lh75ZK0xrRKAPFMOiPLuQ3VtVhcYA= =sq8W -END PGP SIGNATURE- xsa252.meta Description: Binary data xsa252.patch Description: Binary data xsa252-4.6.patch Description: Binary data xsa252-4.7.patch Description: Binary data xsa252-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 256 - x86 PVH guest without LAPIC may DoS the host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-256 version 2 x86 PVH guest without LAPIC may DoS the host UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = So far, x86 PVH guests can be configured with or without Local APICs. Configurations with Local APICs are identical to x86 HVM guests, and will use as much hardware acceleration support as possible. Configurations without Local APICs try to turn off all hardware acceleration, and disable all software emulation. Multiple paths in Xen assume the presence of a Local APIC without sufficient checks, and can fall over a NULL pointer. On Intel hardware, the logic to turn off hardware acceleration is incomplete and leaves the guest with full control of the real Task Priority Register. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == Xen version 4.8 and onwards are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PVH guests can exploit the vulnerability. x86 PV and HVM guests cannot exploit the vulnerability. MITIGATION == Running only PV or HVM guests avoids the vulnerability. Running all PVH guests with "apic=1" in the guest configuration file (or equivalent thereof) also avoids the vulnerability. CREDITS === This issue was discovered by Ian Jackson of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa256.patch xen-unstable, Xen 4.10.x, Xen 4.9.x xsa256-4.8.patch Xen 4.8.x $ sha256sum xsa256* 3e45cc3f2ea516e7470083592041e238c0dfe32324790b2fba0e47c9efe38865 xsa256.patch c029fcb67ff7c3c9a2adcb8e6f5e245a0d347acc8a9b3530591a639cbf321349 xsa256-4.8.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- Version: GnuPG v1 iQEcBAEBCAAGBQJalUe0AAoJEIP+FMlX6CvZsmIH/3B9QnpiL1+NRkGIE62xljEG NfV/vL6gE2ytNMs8PRdhycovQum7qj+l9S53EswiwgiaUFw9VW5Jq9pg1UQlAQ/q 7aIIke33TgkVKwZnb+7ercGfLNWsJAIldGc5emc9lBSBkPOUhFtxmTytdudB6dy1 VMI+MVM1f4xgxEizNN7QstmlaMB34m0WH0nEdoCR8evXlAcmcBi+HwYDouUNnR5x 21DkEBxyslvheX6SI8sbocfrZpT/K2b8B3zdLmd3nO3TF5ypC1daowIk0vl8o4Yj TSx4nsBlJ4V0G0gYa1UDBktUfDbVrpoEcdGb5zO3RhoMhcagzWVD6P6F25aYbiU= =PLNS -END PGP SIGNATURE- xsa256.patch Description: Binary data xsa256-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 12 Information leak via side effects of speculative execution UPDATES IN VERSION 12 = Corrections to ARM SP2 information: * ARM 32-bit requires new firmware on some CPUs. * Provide link to the ARM firmware page, accordingly. * ARM 32-bit mitigations are complete for Cortex-A CPUs. We do not have information for other ARM CPUs at this time. ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public. VULNERABLE SYSTEMS == Systems running
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 11 Information leak via side effects of speculative execution UPDATES IN VERSION 11 = Information provided about migitation for Spectre variant 2. Mention whether CPU hardware virtualisation extensions are required in the SP3 mitigations summary table. An additional patch "x86: fix GET_STACK_END" is required to fix a possible build failure in the PTI patches. README.pti updated accordingly. ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public.
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 9 Information leak via side effects of speculative execution UPDATES IN VERSION 9 "Stage 1" pagetable isolation (PTI) Meltdown fixes for Xen are available. "Comet" updates to shim code (4.10 branch): * Include >32vcpu workaround in shim branch so that all shim guests can boot without hypervisor changes. * Fix shim build on systems whose find(1) lacks -printf * Place shim trampoline at page 0x1 to avoid having 0 mapped (4.8 "Comet" users are using the 4.10 shim and may want to update.) ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January.
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 8
Information leak via side effects of speculative execution
UPDATES IN VERSION 8
PVH shim ("Comet") is now available for Xen 4.8.
Fixes for two bugs in PVH shim "Comet": one relating to shim
initialisation, which can cause hangs during guest boot shortly after
host boot(!), and one to make qemu PV backends work in PVH mode.
Thanks to the respective contributors.
We are longer inclined to port the "Comet" patches to Xen 4.9. If
this causes you a problem please let us know by contacting us:
To: secur...@xenproject.org; CC: xen-devel@lists.xenproject.org
ISSUE DESCRIPTION
=
Processors give the illusion of a sequence of instructions executed
one-by-one. However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel. In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be. If the guess is correct, execution has been sped up. If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all. This is sometimes called "speculative execution".
Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back. These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase. If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.
Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):
"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks. This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.
"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor. Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead. Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).
"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks. On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.
More information is available here:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
Additional Xen-specific background:
Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.
When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level. (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.) However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.
IMPACT
==
Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.
An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers. For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.
Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.
NOTE ON TIMING
==
This
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 7
Information leak via side effects of speculative execution
UPDATES IN VERSION 7
PVH shim ("Comet") for 4.10 tag correction: please use tag
4.10.0-shim-comet-1.1.
ISSUE DESCRIPTION
=
Processors give the illusion of a sequence of instructions executed
one-by-one. However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel. In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be. If the guess is correct, execution has been sped up. If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all. This is sometimes called "speculative execution".
Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back. These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase. If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.
Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):
"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks. This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.
"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor. Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead. Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).
"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks. On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.
More information is available here:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
Additional Xen-specific background:
Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.
When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level. (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.) However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.
IMPACT
==
Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.
An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers. For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.
Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.
NOTE ON TIMING
==
This vulnerability was originally scheduled to be made public on 9
January. It was accelerated at the request of the discloser due to
one of the issues being made public.
VULNERABLE SYSTEMS
==
Systems running all versions of Xen are affected.
For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of
ARM processors to SP1 and SP2 varies by model and manufacturer. ARM
has
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 4 Information leak via side effects of speculative execution UPDATES IN VERSION 4 Added README for determining which shim to use, as well as instructions for using "Vixen" (HVM shim) and the required conversion script ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of ARM processors to SP1
[Xen-devel] Xen Security Advisory 249 (CVE-2017-17563) - broken x86 shadow mode refcount overflow check
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17563 / XSA-249 version 3 broken x86 shadow mode refcount overflow check UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Pages being used to run x86 guests in shadow mode are reference counted to track their uses. Unfortunately the overflow check when trying to obtain a new reference used a mask one bit wider than the reference count actually is, rendering the entire check ineffective. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == Xen versions 4.1 and later are affected. Xen versions 4.0 and earlier are not affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION == For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. xsa249.patch xen-unstable, Xen 4.9.x ... 4.5.x $ sha256sum xsa249* 38a4b8033d634e22939ad42b882c35e46482782619e3e03b968a2f6489e459c9 xsa249.meta e99066b0171d4757c6a66e1223aabe01e990de2d0dc50416936e064e6e750d00 xsa249.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- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXbAAoJEIP+FMlX6CvZdqQH/2b6yXlcScNp9SWs2VIoDLcc Hh3Wxmvx4oRBkdUOiE7/YNJK3yScnW2Jled+fLrBd7yuFNmztlA6Hue1thxgQmFN N2qDReHVBhLDQSv4Xolyifqx/leMo/s7jYkL8zBEPvRrf4DMkj7+i9/JBn8gri8G hiImDmIet9pKL9OP+jQDsgQia5p7ygPVLommMVS/2VZp4O4sBnpvfrAIHNvmmLPy xbr3Jw8cska7gspfmsXU1PziBFmawxk21pvozef9XN1lxC/ZY56yODtph/6KoBvr KGtGleF0QVtj/Nvt42yBr5nMagl9XsjdFz4Jero0K4hOE1Kw7IgO0Oigav8nap8= =Z+E8 -END PGP SIGNATURE- xsa249.meta Description: Binary data xsa249.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 250 (CVE-2017-17564) - improper x86 shadow mode refcount error handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17564 / XSA-250 version 3 improper x86 shadow mode refcount error handling UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Pages being used to run x86 guests in shadow mode are reference counted to track their uses. When another reference cannot be acquired, the corresponding page table entry must not be inserted. Due to incorrect error handling, this constraint could be violated. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == All Xen versions are affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION == For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa250.patch xen-unstable, Xen 4.9.x ... 4.6.x xsa250-4.5.patch Xen 4.5.x $ sha256sum xsa250* c15c1c3e64cfb7ab2e2c48970214aa8c3881deb7e11c498526554bb74535b601 xsa250.meta adf4d8242dbddb4ec52fe1effc1f8b233d33d8d6a59c1bb677dcc6e2ed2bf711 xsa250.patch d123a58308db606185c4e48dcf4a114ac29bb988ffc0eeb04ded213ec474e0f2 xsa250-4.5.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- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXdAAoJEIP+FMlX6CvZeoMH/iS1gZ8zBPWnBCSPm4pUt9ZJ cAJ9vX9E3wDZm0hEQRHOFvTlpqEY3w5TkkBZbErB8m1VD/Om45fZiHvvZRKPtCvK Jks8OVH2Mx2466WladCK4x3km86N2o2547u03dZzZIDUCvn19S8acI1wV8r4TOrv Op4VeDH+cxJ2EAmmrGWkCJc4lQxvJTqzsz+paZ+/dyOdaZGIKJJOhX6s7ZmkjhZz HHr05i+U72kzttUIYqVO4CIp3hoPsOyAcHsd004XGGH6LmWUA7bG1+Fcm+7b2ajD JX/l4xVstD8GWijRnyvOVo/ozRAGb+Nfve+xtVzbyozqVol5PTcP6Jwxerby8PA= =tkcf -END PGP SIGNATURE- xsa250.meta Description: Binary data xsa250.patch Description: Binary data xsa250-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 253 (CVE-2018-5244) - x86: memory leak with MSR emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-5244 / XSA-253 version 3 x86: memory leak with MSR emulation UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. IMPACT == A memory allocation of 8 bytes is leaked each time a vcpu is destroyed. A malicious guest may, by frequently rebooting over extended periods of time, run the system out of memory, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == Xen versions 4.10 and later are affected. Xen 4.9 and earlier are not affected. Only x86 systems are affected. ARM systems are not. All guest kinds can exploit this vulnerability. MITIGATION == Limiting the frequency with which a guest is able to reboot, will limit the memory leak. Rebooting each host (after migrating its guests) periodically will reclaim the leaked space. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa253.patch Xen 4.10, xen-unstable $ sha256sum xsa253* bba1abb5e4368421de29385e37f8477bf3534d3ba3ff7e2aae9c9d3da53f1393 xsa253.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- Version: GnuPG v1 iQEcBAEBCAAGBQJaUOoXAAoJEIP+FMlX6CvZchUIAKlvxu5o9IcIyULARW0s2YEA 6ueK3tyaH2vlWH1IG9KORletdAGALJrfEODt8SBJb+0rKDZKGHSKNB7a911QRebK njXdSpdb1WCdHmStI82csLKvdMGbrFq/6wWFJRt1eFtzr7Qt3rwKXtHv/OI4Kr1T sZ+K6M2KCavkJ+yPSF/f9GTBuD6iiu2E7RI5HzbjdV+k9E7tJkURH2/BPAfhhhyo zsColbPQAxm96RCHIEPaOI5qZXVcfL+5VNbUh5+6vOtUiZdpnOMHmSwDF0AZc1hO 0YQ93/8blRm7N914rn8gu0zY+nQHcgC2klWzHOcCFirzTI0aHXfQQJsX9Oe6g3w= =CX95 -END PGP SIGNATURE- xsa253.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 3 Information leak via side effects of speculative execution UPDATES IN VERSION 3 Add information about ARM vulnerability. Correct description of SP2 difficulty. Mention that resolutions for SP1 and SP3 may be available in the future. Move description of the PV-in-PVH shim from Mitigation to Resolution. (When available and deployed, it will eliminate the SP3 vulnerability.) Add colloquial names and CVEs to the relevant paragraphs in Issue Description. Add a URL. Say explicitly in Vulnerable Systems that HVM guests cannot exploit SP3. Clarify that SP1 and SP2 can be exploited against other victims besides operating systems and hypervisors. Grammar fixes. Remove erroneous detail about when Xen direct maps the whole of physical memory. State in Description that Xen ARM guests run in a separate address space. ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write
[Xen-devel] Xen Security Advisory 253 - x86: memory leak with MSR emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-253 version 2 x86: memory leak with MSR emulation UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. IMPACT == A memory allocation of 8 bytes is leaked each time a vcpu is destroyed. A malicious guest may, by frequently rebooting over extended periods of time, run the system out of memory, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == Xen versions 4.10 and later are affected. Xen 4.9 and earlier are not affected. Only x86 systems are affected. ARM systems are not. All guest kinds can exploit this vulnerability. MITIGATION == Limiting the frequency with which a guest is able to reboot, will limit the memory leak. Rebooting each host (after migrating its guests) periodically will reclaim the leaked space. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa253.patch Xen 4.10, xen-unstable $ sha256sum xsa253* bba1abb5e4368421de29385e37f8477bf3534d3ba3ff7e2aae9c9d3da53f1393 xsa253.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- Version: GnuPG v1 iQEcBAEBCAAGBQJaTiXyAAoJEIP+FMlX6CvZ/CIH/3LEbyAmWUSs4C2Rt0EENDLO JnnAGXWIy3DsffGiG9zOhfYiItn2iD+J+EcO+WC5lGPBSkX1KiXdsWVla/dJuy0F frx5pdqJNSHFihK/6fGU0WnSBFz6o2gkn2hOnzWfpxNLiJMrHCI6GEOcdMx6xtOQ 9QZAa7rCN1aRx0Lx1LjuvaqPwy4rJ294zLnwarMoN10KZ3oRVbQ8mf4kN+/X+hlK 9MxUj99WYZWcJhcRLGiQALPdRQeabh72/ZTFsfIAwPxaEgT6YhwFrFDG526iNcM0 MkruO8HeD+byrQrni/qgB5EAIyPsFuBfvzddHzPA+9sSrf4QDjQWPFihQ3ti+xg= =sQVC -END PGP SIGNATURE- xsa253.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-254 Information leak via side effects of speculative execution ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): SP1, "Bounds-check bypass": Poison the branch predictor, such that operating system or hypervisor code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. SP2, "Branch Target Injection": Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that exists in the hypervisor. SP3, "Rogue Data Load": On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ Additional Xen-specific background: 64-bit Xen hypervisors on systems with less than 5TiB of RAM map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (HVM and PVH guests run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, or SP2 on systems where SMEP (supervisor mode execute protection) is enabled: an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2 without SMEP, or SP3, an attacker can write arbitrary code to speculatively execute. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. For SP1 and SP2, both Intel and AMD are vulnerable. For SP3, only Intel processors are vulnerable. Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH and 32-bit PV guests cannot exploit SP3. We believe that ARM is affected, but unfortunately due to the accelerated schedule, we haven't been able to get concrete input from ARM. We are asking ARM and will publish more information when it is available. MITIGATION == There is no mitigation for SP1 and SP2. SP3 can be mitigated by running guests in HVM or PVH mode. For guests with legacy PV kernels which cannot be run in HVM mode, we have developed a "shim" hypervisor that allows PV guests to run in PVH mode. Unfortunately, due to the accelerated schedule, this is not yet ready to release. We expect
[Xen-devel] Xen Security Advisory 251 - improper bug check in x86 log-dirty handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-251 version 2 improper bug check in x86 log-dirty handling UPDATES IN VERSION 2 Public release. Provide information for Xen 4.10-in-preparation branch in .meta. ISSUE DESCRIPTION = Memory sharing, available to x86 HVM guests only, uses a special value in the global machine to physical address translation table (M2P). PV guests have full control over M2P entries corresponding to pages they own. A bug check (specifically, an assertion that an M2P entry is not the special "shared" indicator) was insufficiently qualified, and as a consequence is triggerable by PV guests in log-dirty mode (e.g. because of being live migrated). IMPACT == A malicious or buggy PV guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == Xen versions 4.0 and later are affected. Xen versions 3.4 and earlier are not affected. Only x86 systems are vulnerable. ARM systems are not vulnerable. x86 HVM guests cannot exploit this vulnerability. Only x86 PV guests can exploit this vulnerability, and only when being run in shadow mode. PV guests are typically run in shadow mode for live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). MITIGATION == Running only HVM guests avoids the vulnerability. Avoiding live migration of x86 PV guests also avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa251.patch xen-unstable, Xen 4.9.x xsa251-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa251-4.5.patch Xen 4.5.x $ sha256sum xsa251* 152cf5c88c3e441af01cdf5749877cabb6ab961afee9f29ae3077e725b703aa2 xsa251.meta 0dfbcfe459f051abb571d3fbedbe9760a4c6cd540ab5d525627050e3eeb9234e xsa251.patch 345a6e004e0d0d89c7fc8db55d48d68f53402a521bd1aa3cb4168043e1ae5673 xsa251-4.5.patch f8cecf013a3628038e0a4566778852a560b25a1ce2f3872a989087ab2fc9a913 xsa251-4.8.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/4UyVfoK9kFAlovuNkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZvOgIALWR2TD54KrdAAtdp0q6b9eo4VcMi5BACeuOIxoY Ek0YA8CLVhj/zmT4/JFH8hZl4Jq0YkWCmxieAw8RvvzFD8WjS7CjTGjseYLL39rZ tyz+GTJ4ws1AVm/HL0JcYqoIWHv3I5M1OdoEKcAyYt4qoHTC00YtQFoSz0Gkruk0 37OMyAfSo3ex+YUpN4S5RXnXB0gdvIOnZJU2WAYYsXxncsOXSP87ohiK55QfK3zO HcSPbcux/NonLG1KqFGzEIXq3wFv1hXo9MGdKnmoeTkr0uaGjxxWySbTyZ5pPzXD Vyr6/W5GwQjee/48KzYEr/UggfeutUpYfSVnW/KL/CCqqy0= =sgSx -END PGP SIGNATURE- xsa251.meta Description: Binary data xsa251.patch Description: Binary data xsa251-4.5.patch Description: Binary data xsa251-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 250 - improper x86 shadow mode refcount error handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-250 version 2 improper x86 shadow mode refcount error handling UPDATES IN VERSION 2 Public release. Provide metadata file. ISSUE DESCRIPTION = Pages being used to run x86 guests in shadow mode are reference counted to track their uses. When another reference cannot be acquired, the corresponding page table entry must not be inserted. Due to incorrect error handling, this constraint could be violated. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == All Xen versions are affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION == For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa250.patch xen-unstable, Xen 4.9.x ... 4.6.x xsa250-4.5.patch Xen 4.5.x $ sha256sum xsa250* c15c1c3e64cfb7ab2e2c48970214aa8c3881deb7e11c498526554bb74535b601 xsa250.meta adf4d8242dbddb4ec52fe1effc1f8b233d33d8d6a59c1bb677dcc6e2ed2bf711 xsa250.patch d123a58308db606185c4e48dcf4a114ac29bb988ffc0eeb04ded213ec474e0f2 xsa250-4.5.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/4UyVfoK9kFAlovuNkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZx+4H/2ADwtz7LzqBd7aZ9BnODa3L+KM/hO05tG0t+feh eunJSfxAY3jRep4NxWUgK8zerAusw3zZi9lRzmhdLMHYtmslJPDWy5ul0N09E6Y5 KH2Ky8zkFb2puzHZs2oMKywW25aRI6Bs7VdFK44KxWPRrLAFTNup6xOCVNWJ4VWw YhNTu4g/+mUUa+KLRPL/s6sKjIw07/sbh/koHWSwlAksxmlUfdHaFuLbsvspPRe0 vq8Q8zN/n9Att6i8RrjeWLAb36mYXhKYIzkZhmJXNlwQx9dkhuLdlRaJ4zb7uERb wDYYlT9wib8CB5tsKxX+ozLQ0mr43DAFfsLJpzi7TudYplE= =+/I2 -END PGP SIGNATURE- xsa250.meta Description: Binary data xsa250.patch Description: Binary data xsa250-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 248 - x86 PV guests may gain access to internally used pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-248 version 2 x86 PV guests may gain access to internally used pages UPDATES IN VERSION 2 Public release. Provide metadata file. ISSUE DESCRIPTION = Memory management for PV guests builds on page ownership and page attributes. A domain can always map, at least r/o, pages of which it is the owner. Certain fields in the control structure of a page are used for different purposes in the main PV memory management code and in code handling shadow paging. When a guest is running in shadow mode (which for PV guests is necessary e.g. for live migration), certain auxiliary pages used by Xen internally had their owner set to the guest itself. When the PV guest maps such a page, shadow code and PV memory management code will disagree on the meaning of said multi-purpose fields, generally leading to a crash of the hypervisor. IMPACT == A malicious or buggy PV guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. x86 HVM guests cannot exploit this vulnerability. Only x86 PV guests can exploit this vulnerability, and only when being run in shadow mode. PV guests are typically run in shadow mode for live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). MITIGATION == Running only HVM guests avoids the vulnerability. Avoiding live migration of x86 PV guests also avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa248.patch xen-unstable, Xen 4.9.x xsa248-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa248-4.5.patch Xen 4.5.x $ sha256sum xsa248* f0ac5c5ff956118f52821e111c6e27416f788cea6e98cc54cb051c42b793357e xsa248.meta 20bcfb1890d90bd74f52e45a1e8aa020a8991e3a0db37eecf53ce48b16e602bf xsa248.patch ec4227633df18f76fbd8cb12e367879470b63fb5236f10b2a971dccef9f83172 xsa248-4.5.patch 3bbd9fd92e5ffab1ddd7ff804bfbab09c1c654af3aa7f80f742f321da120b715 xsa248-4.8.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/4UyVfoK9kFAlovuMMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZy20H/0z0FHbgG05yJtRNRZZ6p/YuygBi7yiuddoa1BTX jVHYBd6TBw577qVYCGv77+ta4RhZdmg+qjVayzMQy0r07maq8jbNse7bTfjkbS8L levYk0Yjr03jDRWW4//WurV9vlxgoTRGSjz3RlbqPPC/ugpZbj8VrrqOxqhV5dhR umZSXIFQroZrDsHeAl+or84h+psSvGYcUnuMI/ML96hBqUjVi/owLIPhJw3OzK1i VBQTuBAVWYR1CVIGq1KQCEpKD0NbRC3M0+cxDibdhwH+Md0O947m0W8fA5p3hYdg e8CwuA0pk6CVKkFummEcC5FvwQStyVZjgG+X7aOwXobsMlA= =aj+p -END PGP SIGNATURE- xsa248.meta Description: Binary data xsa248.patch Description: Binary data xsa248-4.5.patch Description: Binary data xsa248-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 249 - broken x86 shadow mode refcount overflow check
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-249 version 2 broken x86 shadow mode refcount overflow check UPDATES IN VERSION 2 Public release. Provide metadata file. ISSUE DESCRIPTION = Pages being used to run x86 guests in shadow mode are reference counted to track their uses. Unfortunately the overflow check when trying to obtain a new reference used a mask one bit wider than the reference count actually is, rendering the entire check ineffective. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == Xen versions 4.1 and later are affected. Xen versions 4.0 and earlier are not affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION == For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. xsa249.patch xen-unstable, Xen 4.9.x ... 4.5.x $ sha256sum xsa249* 38a4b8033d634e22939ad42b882c35e46482782619e3e03b968a2f6489e459c9 xsa249.meta e99066b0171d4757c6a66e1223aabe01e990de2d0dc50416936e064e6e750d00 xsa249.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/4UyVfoK9kFAlovuNkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZD0AIAJN95Z7d9zV07qt4q1iPyyvmBnhusedCvZmTnJTr +nfYb/mg9H7C8Re3Fsf0RA66P+nA8a76HVC3kqBBuqUvE+QNHteWmVWZ6K7QbtlG cCW6CtjeT0be98G1KyvIhL6rLYjpB/4LWAeXusof6ckcbtxHBRtGL3kQhv3MN91q u/R9nHKUyIYS/G4J39ApHk0XOFJFFg9mx66HhZuMjJMjBDevT+EG516YerXlSWr9 bskfxPICFSC7g8z5I2mYdrAxinJ2QHpzurw2Q3T+adb2ag+ClkZRu3gS9jNHuC3F vqQr0r0LE68t77A2uD7UKyXuU5+kQ61yBE780I6BkhiG4PI= =0o90 -END PGP SIGNATURE- xsa249.meta Description: Binary data xsa249.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 238 (CVE-2017-15591) - DMOP map/unmap missing argument checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15591 / XSA-238 version 3 DMOP map/unmap missing argument checks UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = DMOPs (which were a subgroup of HVMOPs in older releases) allow guests to control and drive other guests. The I/O request server page mapping interface uses range sets to represent I/O resources the emulation of which is provided by a given I/O request server. The internals of the range set implementation require that ranges have a starting value no lower than the ending one. Checks for this fact were missing. IMPACT == Malicious or buggy stub domain kernels or tool stacks otherwise living outside of Domain0 can mount a denial of service attack which, if successful, can affect the whole system. Only domains controlling HVM guests can exploit this vulnerability. (This includes domains providing hardware emulation services to HVM guests.) VULNERABLE SYSTEMS == Xen versions 4.5 and later are vulnerable. Xen versions 4.4 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. This vulnerability is only applicable to Xen systems using stub domains or other forms of disaggregation of control domains for HVM guests. MITIGATION == Running only PV guests will avoid this issue. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS === This issue was discovered by Vitaly Kuznetsov of RedHat. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa238.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa238-4.6.patch Xen 4.6.x xsa238-4.5.patch Xen 4.5.x $ sha256sum xsa238* 93cc1da4a0ab27f857f2ad39c38f112ef101a01bc5d386807d27371f83526831 xsa238.meta 85d3f9713bef1bc86c682857dbd7388a1d1f20089363ddfc4cb9ecbd88eaffec xsa238.patch 034e91c234f6831dbaa1aaf29f4f90de2e822f99301424f7f3527f9da883ff68 xsa238-4.5.patch 29255a81729b24866e594426167de5fbef70de21ef62a95ba95de191d2a7fd54 xsa238-4.6.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- Version: GnuPG v1 iQEcBAEBCAAGBQJaJ82OAAoJEIP+FMlX6CvZcU0IAMkUqTbbTWIWAruO03YSxFvn bqmfyzgyUVHUMLzhjrukaqVxZYcxV5FbY/IMWEZY/oET9wHv8iBsMay+cVlsv45i GMHZaxGBM9P1xU6AS4GP/oRMb9LA4fU7rjCKcK54zaDV+mdW/2rA+Ac0IVbmn3tF gcnkfbHk3cF8x91rD4+2ZC7ihE6CIX70PQxdXNbgR8RpoxGdE1q9IPF8ik3gLyO/ OtoDfqrbau+YllhTBI3XxmU+MJgpRf+VRnOgFpYjzp10dfVBM459Lmdzfa6gXhxz ysm+Js8Y4jpVEIGY3qXAV8/V2ZSL8nNmFiNFPOJZcNu4wkAFZKUlyWBbFlJcvvk= =keh/ -END PGP SIGNATURE- xsa238.meta Description: Binary data xsa238.patch Description: Binary data xsa238-4.5.patch Description: Binary data xsa238-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 247 (CVE-2017-17045) - Missing p2m error checking in PoD code
-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
[Xen-devel] Xen Security Advisory 246 (CVE-2017-17044) - x86: infinite loop due to missing PoD error checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17044 / XSA-246 version 3 x86: infinite loop due to missing PoD error checking UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Failure to recognize errors being returned from low level functions in Populate on Demand (PoD) code may result in higher level code entering an infinite loop. IMPACT == A malicious HVM guest can cause one pcpu to permanently hang. This normally cascades into the whole system freezing, resulting in a a host Denial of Service (DoS). VULNERABLE SYSTEMS == Xen versions from 3.4.x onwards are affected. 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 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 Julien Grall of Linaro. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa246.patch xen-unstable xsa246-4.9.patch Xen 4.9.x, Xen 4.8.x xsa246-4.7.patch Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa246* df08a3be419f2384b495dc52c3e6ebef1eb67d8b562afe85fb6fe6a723334472 xsa246.patch b41550688e88a2a7a22349a07168f3a3ddf6fad8b3389fa27de44ae6731b6a8b xsa246-4.7.patch ea591542774c22db65dcb340120cebf58e759670b5a9fbde42ee93ed594650c8 xsa246-4.9.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/KNAAoJEIP+FMlX6CvZi5sIAJojGRp1oewRc3JkEolFITBb EcQDq9n7ppd21q+hRmYKT+IwRILahxGFbfQJHzCbu9KHFNswt9dgFNlkBk2Jk+rD q3LzoSeIBrNVazfIX6VpGtgrPxlsAJzsmvAp5LgdZ+H3tYqsHYdyeoaPFAtbuB40 6WgBWv2Z003uRCvK5F8ka3cRrWsuuiae9gnUKfLjt4eAu7rES8wFG+VE4n/o6RLg YJuyCL97rYXgBRAABO/1bR7mKWhyux3WbtZjjDSnUcn+O3UOpVH49bL5JHb1XKuS ycdwYtfjTwB7nB1o7TnYGEQKieqlWDWOylWTWJxA3cOsIHHB2syTV3L9vVukti0= =CmSs -END PGP SIGNATURE- xsa246.patch Description: Binary data xsa246-4.7.patch Description: Binary data xsa246-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 245 (CVE-2017-17046) - ARM: Some memory not scrubbed at boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17046 / XSA-245 version 2 ARM: Some memory not scrubbed at boot UPDATES IN VERSION 2 CVE assigned. NOTE REGARDING LACK OF EMBARGO == This bug was discussed publicly before it was realised that it was a security vulnerability. ISSUE DESCRIPTION = Data can remain readable in DRAM across soft and even hard reboots. To ensure that sensitive data is not leaked from one domain to another after a reboot, Xen must "scrub" all memory on boot (write it with zeroes). Unfortunately, it was discovered that when memory was in disjoint blocks, or when the first block didn't begin at physical address 0, arithmetic errors meant that some memory was not scrubbed. IMPACT == Sensitive information from one domain before a reboot might be visible to another domain after a reboot. VULNERABLE SYSTEMS == Only ARM systems are vulnerable. All versions of Xen since 4.5 are vulnerable. Only hardware with disjoint blocks, or physical addresses not starting at 0 are vulnerable; this includes the majority of ARM systems. MITIGATION == None. RESOLUTION == Applying the appropriate attached patches resolves this issue. xsa245/*.patch All versions of Xen $ sha256sum xsa245* xsa245*/* 121829263b85fcb5eac8e38fb44e77d3aab1dd7ae6ef665bf84bb49e5e161d24 xsa245.meta 526f9e1b127fbb316762ce8e8f4563bc9de0c55a1db581456a3017d570d35bdd xsa245/0001-xen-page_alloc-Cover-memory-unreserved-after-boot-in.patch 7164010112fcccd9cd88e72ace2eeabdb364dd6f4d05c434686267d18067f420 xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaH/KMAAoJEIP+FMlX6CvZMfgH/j86RZD7z55Lt7ITlLWZwucP uTDw8gjJRtB/8mgrJq97Q37rWBHvvfITUYHW7wxA+LJQAje2X7y+3kV4EWpF0hFI BMU3QfeyTCgYbmTb0NOaULGzhDtN/QKjFq48fccnRYfg7MisIEy5dVqDWnbUQfIn STP/w63rpjx2mpZVSBuWC+yA0mjcaCyezR6xJoN1rQjVe/FrnzoJwCYBmpR3JY9+ AIeRvLLpK/vbREZZxOpBioL9KQxH+zahIwQJkS56Jbt8uC1Fq0UFe809Xt+8I4d+ yOJiflkHKgFBW1KUL1Pirq+koad1p66Ciz9c8j88Wop0fhDTQdn10mbteizOM64= =PRKQ -END PGP SIGNATURE- xsa245.meta Description: Binary data xsa245/0001-xen-page_alloc-Cover-memory-unreserved-after-boot-in.patch Description: Binary data xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 247 - Missing p2m error checking in PoD code
-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
