svn commit: r427795 - head/security/vuxml
Jason Unovitch
junovitch at FreeBSD.org
Sun Dec 4 19:35:15 UTC 2016
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>
More information about the svn-ports-all
mailing list