Date: Sun, 4 Dec 2016 19:35:14 +0000 (UTC) From: Jason Unovitch <junovitch@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r427795 - head/security/vuxml Message-ID: <201612041935.uB4JZEbD065092@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: junovitch Date: Sun Dec 4 19:35:14 2016 New Revision: 427795 URL: https://svnweb.freebsd.org/changeset/ports/427795 Log: Document Xen Security Advisories (XSAs 185-188, 190-195, 197-198) PR: 214936 Security: CVE-2016-7092 Security: CVE-2016-7093 Security: CVE-2016-7094 Security: CVE-2016-7154 Security: CVE-2016-7777 Security: CVE-2016-9379 Security: CVE-2016-9380 Security: CVE-2016-9381 Security: CVE-2016-9382 Security: CVE-2016-9383 Security: CVE-2016-9384 Security: CVE-2016-9385 Security: CVE-2016-9386 Security: https://vuxml.FreeBSD.org/freebsd/45ca25b5-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/49211361-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/4aae54be-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/4d7cf654-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/50ac2e96-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/523bb0b7-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/53dbd096-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/5555120d-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/56f0f11e-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/58685e23-ba4d-11e6-ae1b-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/59f79c99-ba4d-11e6-ae1b-002590263bf5.html Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Sun Dec 4 18:41:05 2016 (r427794) +++ head/security/vuxml/vuln.xml Sun Dec 4 19:35:14 2016 (r427795) @@ -58,6 +58,444 @@ Notes: * Do not forget port variants (linux-f10-libxml2, libxml2, etc.) --> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">; + <vuln vid="59f79c99-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-tools -- delimiter injection vulnerabilities in pygrub</topic> + <affects> + <package> + <name>xen-tools</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-198.html">; + <p>pygrub, the boot loader emulator, fails to quote (or sanity check) + its results when reporting them to its caller.</p> + <p>A malicious guest administrator can obtain the contents of + sensitive host files (an information leak). Additionally, a + malicious guest administrator can cause files on the host to be + removed, causing a denial of service. In some unusual host + configurations, ability to remove certain files may be useable for + privilege escalation.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9379</cvename> + <cvename>CVE-2016-9380</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-198.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="58685e23-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-tools -- qemu incautious about shared ring processing</topic> + <affects> + <package> + <name>xen-tools</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-197.html">; + <p>The compiler can emit optimizations in qemu which can lead to + double fetch vulnerabilities. Specifically data on the rings shared + between qemu and the hypervisor (which the guest under control can + obtain mappings of) can be fetched twice (during which time the + guest can alter the contents) possibly leading to arbitrary code + execution in qemu.</p> + <p>Malicious administrators can exploit this vulnerability to take + over the qemu process, elevating its privilege to that of the qemu + process.</p> + <p>In a system not using a device model stub domain (or other + techniques for deprivileging qemu), malicious guest administrators + can thus elevate their privilege to that of the host.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9381</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-197.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="56f0f11e-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86 64-bit bit test instruction emulation broken</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-195.html">; + <p>The x86 instructions BT, BTC, BTR, and BTS, when used with a + destination memory operand and a source register rather than an + immediate operand, access a memory location offset from that + specified by the memory operand as specified by the high bits of + the register source.</p> + <p>A malicious guest can modify arbitrary memory, allowing for + arbitrary code execution (and therefore privilege escalation + affecting the whole host), a crash of the host (leading to a DoS), + or information leaks. The vulnerability is sometimes exploitable + by unprivileged guest user processes.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9383</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-195.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="5555120d-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- guest 32-bit ELF symbol table load leaking host data</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>4.7</ge><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-194.html">; + <p>Along with their main kernel binary, unprivileged guests may + arrange to have their Xen environment load (kernel) symbol tables + for their use. The ELF image metadata created for this purpose has a + few unused bytes when the symbol table binary is in 32-bit ELF + format. These unused bytes were not properly cleared during symbol + table loading.</p> + <p>A malicious unprivileged guest may be able to obtain sensitive + information from the host.</p> + <p>The information leak is small and not under the control of the + guest, so effectively exploiting this vulnerability is probably + difficult.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9384</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-194.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="53dbd096-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86 segment base write emulation lacking canonical address checks</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>4.4</ge><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-193.html">; + <p>Both writes to the FS and GS register base MSRs as well as the + WRFSBASE and WRGSBASE instructions require their input values to be + canonical, or a #GP fault will be raised. When the use of those + instructions by the hypervisor was enabled, the previous guard + against #GP faults (having recovery code attached) was accidentally + removed.</p> + <p>A malicious guest administrator can crash the host, leading to a + DoS.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9385</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-193.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="523bb0b7-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86 task switch to VM86 mode mis-handled</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-192.html">; + <p>LDTR, just like TR, is purely a protected mode facility. Hence even + when switching to a VM86 mode task, LDTR loading needs to follow + protected mode semantics. This was violated by the code.</p> + <p>On SVM (AMD hardware): a malicious unprivileged guest process can + escalate its privilege to that of the guest operating system.</p> + <p>On both SVM and VMX (Intel hardware): a malicious unprivileged + guest process can crash the guest.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9382</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-192.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="50ac2e96-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86 null segments not always treated as unusable</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-191.html">; + <p>The Xen x86 emulator erroneously failed to consider the unusability + of segments when performing memory accesses.</p> + <p> The intended behaviour is as follows: The user data segment (%ds, + %es, %fs and %gs) selectors may be NULL in 32-bit to prevent access. + In 64-bit, NULL has a special meaning for user segments, and there + is no way of preventing access. However, in both 32-bit and 64-bit, + a NULL LDT system segment is intended to prevent access.</p> + <p>On Intel hardware, loading a NULL selector zeros the base as well + as most attributes, but sets the limit field to its largest possible + value. On AMD hardware, loading a NULL selector zeros the attributes, + leaving the stale base and limit intact.</p> + <p>Xen may erroneously permit the access using unexpected base/limit + values.</p> + <p>Ability to exploit this vulnerability on Intel is easy, but on AMD + depends in a complicated way on how the guest kernel manages LDTs. + </p> + <p>An unprivileged guest user program may be able to elevate its + privilege to that of the guest operating system.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-9386</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-191.html</url>; + </references> + <dates> + <discovery>2016-11-22</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="4d7cf654-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- CR0.TS and CR0.EM not always honored for x86 HVM guests</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-190.html">; + <p>Instructions touching FPU, MMX, or XMM registers are required to + raise a Device Not Available Exception (#NM) when either CR0.EM or + CR0.TS are set. (Their AVX or AVX-512 extensions would consider only + CR0.TS.) While during normal operation this is ensured by the + hardware, if a guest modifies instructions while the hypervisor is + preparing to emulate them, the #NM delivery could be missed.</p> + <p>Guest code in one task may thus (unintentionally or maliciously) + read or modify register state belonging to another task in the same + VM.</p> + <p>A malicious unprivileged guest user may be able to obtain or + corrupt sensitive information (including cryptographic material) in + other programs in the same guest.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-7777</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-190.html</url>; + </references> + <dates> + <discovery>2016-10-04</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="4bf57137-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- use after free in FIFO event channel code</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>4.4</ge><lt>4.5</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-188.html">; + <p>When the EVTCHNOP_init_control operation is called with a bad guest + frame number, it takes an error path which frees a control structure + without also clearing the corresponding pointer. Certain subsequent + operations (EVTCHNOP_expand_array or another EVTCHNOP_init_control), + upon finding the non-NULL pointer, continue operation assuming it + points to allocated memory.</p> + <p>A malicious guest administrator can crash the host, leading to a + DoS. Arbitrary code execution (and therefore privilege escalation), + and information leaks, cannot be excluded.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-7154</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-188.html</url>; + </references> + <dates> + <discovery>2016-09-08</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="4aae54be-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86 HVM: Overflow of sh_ctxt->seg_reg[]</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-187.html">; + <p>x86 HVM guests running with shadow paging use a subset of the x86 + emulator to handle the guest writing to its own pagetables. There + are situations a guest can provoke which result in exceeding the + space allocated for internal state.</p> + <p>A malicious HVM guest administrator can cause Xen to fail a bug + check, causing a denial of service to the host.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-7094</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-187.html</url>; + </references> + <dates> + <discovery>2016-09-08</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="49211361-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86: Mishandling of instruction pointer truncation during emulation</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><eq>4.5.3</eq></range> + <range><eq>4.6.3</eq></range> + <range><ge>4.7.0</ge><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-186.html">; + <p>When emulating HVM instructions, Xen uses a small i-cache for + fetches from guest memory. The code that handles cache misses does + not check if the address from which it fetched lies within the cache + before blindly writing to it. As such it is possible for the guest + to overwrite hypervisor memory.</p> + <p>It is currently believed that the only way to trigger this bug is + to use the way that Xen currently incorrectly wraps CS:IP in 16 bit + modes. The included patch prevents such wrapping.</p> + <p>A malicious HVM guest administrator can escalate their privilege to + that of the host.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-7093</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-186.html</url>; + </references> + <dates> + <discovery>2016-09-08</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + + <vuln vid="45ca25b5-ba4d-11e6-ae1b-002590263bf5"> + <topic>xen-kernel -- x86: Disallow L3 recursive pagetable for 32-bit PV guests</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.7.1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="https://xenbits.xen.org/xsa/advisory-185.html">; + <p>On real hardware, a 32-bit PAE guest must leave the USER and RW bit + clear in L3 pagetable entries, but the pagetable walk behaves as if + they were set. (The L3 entries are cached in processor registers, + and don't actually form part of the pagewalk.)</p> + <p>When running a 32-bit PV guest on a 64-bit Xen, Xen must always OR + in the USER and RW bits for L3 updates for the guest to observe + architectural behaviour. This is unsafe in combination with + recursive pagetables.</p> + <p>As there is no way to construct an L3 recursive pagetable in native + 32-bit PAE mode, disallow this option in 32-bit PV guests.</p> + <p>A malicious 32-bit PV guest administrator can escalate their + privilege to that of the host.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2016-7092</cvename> + <freebsdpr>ports/214936</freebsdpr> + <url>https://xenbits.xen.org/xsa/advisory-185.html</url>; + </references> + <dates> + <discovery>2016-09-08</discovery> + <entry>2016-12-04</entry> + </dates> + </vuln> + <vuln vid="7fff2b16-b0ee-11e6-86b8-589cfc054129"> <topic>wireshark -- multiple vulnerabilities</topic> <affects>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201612041935.uB4JZEbD065092>