xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-2019-19579 CVE-2019-19580 CVE-2019-19581 CVE-2019-19582 CVE-2019-19583)

Debian Bug report logs - #947944
xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-2019-19579 CVE-2019-19580 CVE-2019-19581 CVE-2019-19582 CVE-2019-19583)

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-2019-19579 CVE-2019-19580 CVE-2019-19581 CVE-2019-19582 CVE-2019-19583)

Date: Thu, 02 Jan 2020 15:57:17 +0100

Source: xen
Version: 4.11.1+92-g6c33308a8d-2
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

There are several CVEs open for xen up to unstable, compiling a list
from the information from the security-tracker it looks those below.

Any progress in getting those fixed at least for unstable already?

CVE-2018-12207[0]:
| Improper invalidation for page table updates by a virtual guest
| operating system for multiple Intel(R) Processors may allow an
| authenticated user to potentially enable denial of service of the host
| system via local access.


CVE-2019-11135[1]:
| TSX Asynchronous Abort condition on some CPUs utilizing speculative
| execution may allow an authenticated user to potentially enable
| information disclosure via a side channel with local access.


CVE-2019-18420[2]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to cause a denial of service via a VCPUOP_initialise hypercall.
| hypercall_create_continuation() is a variadic function which uses a
| printf-like format string to interpret its parameters. Error handling
| for a bad format character was done using BUG(), which crashes Xen.
| One path, via the VCPUOP_initialise hypercall, has a bad format
| character. The BUG() can be hit if VCPUOP_initialise executes for a
| sufficiently long period of time for a continuation to be created.
| Malicious guests may cause a hypervisor crash, resulting in a Denial
| of Service (DoS). Xen versions 4.6 and newer are vulnerable. Xen
| versions 4.5 and earlier are not vulnerable. Only x86 PV guests can
| exploit the vulnerability. HVM and PVH guests, and guests on ARM
| systems, cannot exploit the vulnerability.


CVE-2019-18421[3]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to gain host OS privileges by leveraging race conditions in
| pagetable promotion and demotion operations. There are issues with
| restartable PV type change operations. To avoid using shadow
| pagetables for PV guests, Xen exposes the actual hardware pagetables
| to the guest. In order to prevent the guest from modifying these page
| tables directly, Xen keeps track of how pages are used using a type
| system; pages must be "promoted" before being used as a pagetable, and
| "demoted" before being used for any other type. Xen also allows for
| "recursive" promotions: i.e., an operating system promoting a page to
| an L4 pagetable may end up causing pages to be promoted to L3s, which
| may in turn cause pages to be promoted to L2s, and so on. These
| operations may take an arbitrarily large amount of time, and so must
| be re-startable. Unfortunately, making recursive pagetable promotion
| and demotion operations restartable is incredibly complicated, and the
| code contains several races which, if triggered, can cause Xen to drop
| or retain extra type counts, potentially allowing guests to get write
| access to in-use pagetables. A malicious PV guest administrator may be
| able to escalate their privilege to that of the host. All x86 systems
| with untrusted PV guests are vulnerable. HVM and PVH guests cannot
| exercise this vulnerability.


CVE-2019-18422[4]:
| An issue was discovered in Xen through 4.12.x allowing ARM guest OS
| users to cause a denial of service or gain privileges by leveraging
| the erroneous enabling of interrupts. Interrupts are unconditionally
| unmasked in exception handlers. When an exception occurs on an ARM
| system which is handled without changing processor level, some
| interrupts are unconditionally enabled during exception entry. So
| exceptions which occur when interrupts are masked will effectively
| unmask the interrupts. A malicious guest might contrive to arrange for
| critical Xen code to run with interrupts erroneously enabled. This
| could lead to data corruption, denial of service, or possibly even
| privilege escalation. However a precise attack technique has not been
| identified.


CVE-2019-18423[5]:
| An issue was discovered in Xen through 4.12.x allowing ARM guest OS
| users to cause a denial of service via a XENMEM_add_to_physmap
| hypercall. p2m->max_mapped_gfn is used by the functions
| p2m_resolve_translation_fault() and p2m_get_entry() to sanity check
| guest physical frame. The rest of the code in the two functions will
| assume that there is a valid root table and check that with BUG_ON().
| The function p2m_get_root_pointer() will ignore the unused top bits of
| a guest physical frame. This means that the function p2m_set_entry()
| will alias the frame. However, p2m->max_mapped_gfn will be updated
| using the original frame. It would be possible to set
| p2m->max_mapped_gfn high enough to cover a frame that would lead
| p2m_get_root_pointer() to return NULL in p2m_get_entry() and
| p2m_resolve_translation_fault(). Additionally, the sanity check on
| p2m->max_mapped_gfn is off-by-one allowing "highest mapped + 1" to
| be considered valid. However, p2m_get_root_pointer() will return NULL.
| The problem could be triggered with a specially crafted hypercall
| XENMEM_add_to_physmap{, _batch} followed by an access to an address
| (via hypercall or direct access) that passes the sanity check but
| cause p2m_get_root_pointer() to return NULL. A malicious guest
| administrator may cause a hypervisor crash, resulting in a Denial of
| Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm
| systems are vulnerable. x86 systems are not affected.


CVE-2019-18424[6]:
| An issue was discovered in Xen through 4.12.x allowing attackers to
| gain host OS privileges via DMA in a situation where an untrusted
| domain has access to a physical device. This occurs because passed
| through PCI devices may corrupt host memory after deassignment. When a
| PCI device is assigned to an untrusted domain, it is possible for that
| domain to program the device to DMA to an arbitrary address. The IOMMU
| is used to protect the host from malicious DMA by making sure that the
| device addresses can only target memory assigned to the guest.
| However, when the guest domain is torn down, or the device is
| deassigned, the device is assigned back to dom0, thus allowing any in-
| flight DMA to potentially target critical host data. An untrusted
| domain with access to a physical device can DMA into host memory,
| leading to privilege escalation. Only systems where guests are given
| direct access to physical devices capable of DMA (PCI pass-through)
| are vulnerable. Systems which do not use PCI pass-through are not
| vulnerable.


CVE-2019-18425[7]:
| An issue was discovered in Xen through 4.12.x allowing 32-bit PV guest
| OS users to gain guest OS privileges by installing and using
| descriptors. There is missing descriptor table limit checking in x86
| PV emulation. When emulating certain PV guest operations, descriptor
| table accesses are performed by the emulating code. Such accesses
| should respect the guest specified limits, unless otherwise guaranteed
| to fail in such a case. Without this, emulation of 32-bit guest user
| mode calls through call gates would allow guest user mode to install
| and then use descriptors of their choice, as long as the guest kernel
| did not itself install an LDT. (Most OSes don't install any LDT by
| default). 32-bit PV guest user mode can elevate its privileges to that
| of the guest kernel. Xen versions from at least 3.2 onwards are
| affected. Only 32-bit PV guest user mode can leverage this
| vulnerability. HVM, PVH, as well as 64-bit PV guests cannot leverage
| this vulnerability. Arm systems are unaffected.


CVE-2019-19577[8]:
| An issue was discovered in Xen through 4.12.x allowing x86 AMD HVM
| guest OS users to cause a denial of service or possibly gain
| privileges by triggering data-structure access during pagetable-height
| updates. When running on AMD systems with an IOMMU, Xen attempted to
| dynamically adapt the number of levels of pagetables (the pagetable
| height) in the IOMMU according to the guest's address space size. The
| code to select and update the height had several bugs. Notably, the
| update was done without taking a lock which is necessary for safe
| operation. A malicious guest administrator can cause Xen to access
| data structures while they are being modified, causing Xen to crash.
| Privilege escalation is thought to be very difficult but cannot be
| ruled out. Additionally, there is a potential memory leak of 4kb per
| guest boot, under memory pressure. Only Xen on AMD CPUs is vulnerable.
| Xen running on Intel CPUs is not vulnerable. ARM systems are not
| vulnerable. Only systems where guests are given direct access to
| physical devices are vulnerable. Systems which do not use PCI pass-
| through are not vulnerable. Only HVM guests can exploit the
| vulnerability. PV and PVH guests cannot. All versions of Xen with
| IOMMU support are vulnerable.


CVE-2019-19578[9]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to cause a denial of service via degenerate chains of linear
| pagetables, because of an incorrect fix for CVE-2017-15595. "Linear
| pagetables" is a technique which involves either pointing a pagetable
| at itself, or to another pagetable of the same or higher level. Xen
| has limited support for linear pagetables: A page may either point to
| itself, or point to another pagetable of the same level (i.e., L2 to
| L2, L3 to L3, and so on). XSA-240 introduced an additional restriction
| that limited the "depth" of such chains by allowing pages to either
| *point to* other pages of the same level, or *be pointed to* by other
| pages of the same level, but not both. To implement this, we keep
| track of the number of outstanding times a page points to or is
| pointed to another page table, to prevent both from happening at the
| same time. Unfortunately, the original commit introducing this reset
| this count when resuming validation of a partially-validated
| pagetable, incorrectly dropping some "linear_pt_entry" counts. If an
| attacker could engineer such a situation to occur, they might be able
| to make loops or other arbitrary chains of linear pagetables, as
| described in XSA-240. A malicious or buggy PV guest may cause the
| hypervisor to crash, resulting in Denial of Service (DoS) affecting
| the entire host. Privilege escalation and information leaks cannot be
| excluded. All versions of Xen are vulnerable. Only x86 systems are
| affected. Arm systems are not affected. Only x86 PV guests can
| leverage the vulnerability. x86 HVM and PVH guests cannot leverage the
| vulnerability. Only systems which have enabled linear pagetables are
| vulnerable. Systems which have disabled linear pagetables, either by
| selecting CONFIG_PV_LINEAR_PT=n when building the hypervisor, or
| adding pv-linear-pt=false on the command-line, are not vulnerable.


CVE-2019-19579[10]:
| An issue was discovered in Xen through 4.12.x allowing attackers to
| gain host OS privileges via DMA in a situation where an untrusted
| domain has access to a physical device (and assignable-add is not
| used), because of an incomplete fix for CVE-2019-18424. XSA-302 relies
| on the use of libxl's "assignable-add" feature to prepare devices to
| be assigned to untrusted guests. Unfortunately, this is not considered
| a strictly required step for device assignment. The PCI passthrough
| documentation on the wiki describes alternate ways of preparing
| devices for assignment, and libvirt uses its own ways as well. Hosts
| where these "alternate" methods are used will still leave the system
| in a vulnerable state after the device comes back from a guest. An
| untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation. Only systems where guests are
| given direct access to physical devices capable of DMA (PCI pass-
| through) are vulnerable. Systems which do not use PCI pass-through are
| not vulnerable.


CVE-2019-19580[11]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to gain host OS privileges by leveraging race conditions in
| pagetable promotion and demotion operations, because of an incomplete
| fix for CVE-2019-18421. XSA-299 addressed several critical issues in
| restartable PV type change operations. Despite extensive testing and
| auditing, some corner cases were missed. A malicious PV guest
| administrator may be able to escalate their privilege to that of the
| host. All security-supported versions of Xen are vulnerable. Only x86
| systems are affected. Arm systems are not affected. Only x86 PV guests
| can leverage the vulnerability. x86 HVM and PVH guests cannot leverage
| the vulnerability. Note that these attacks require very precise
| timing, which may be difficult to exploit in practice.


CVE-2019-19581[12]:
| An issue was discovered in Xen through 4.12.x allowing 32-bit Arm
| guest OS users to cause a denial of service (out-of-bounds access)
| because certain bit iteration is mishandled. In a number of places
| bitmaps are being used by the hypervisor to track certain state.
| Iteration over all bits involves functions which may misbehave in
| certain corner cases: On 32-bit Arm accesses to bitmaps with bit a
| count which is a multiple of 32, an out of bounds access may occur. A
| malicious guest may cause a hypervisor crash or hang, resulting in a
| Denial of Service (DoS). All versions of Xen are vulnerable. 32-bit
| Arm systems are vulnerable. 64-bit Arm systems are not vulnerable.


CVE-2019-19582[13]:
| An issue was discovered in Xen through 4.12.x allowing x86 guest OS
| users to cause a denial of service (infinite loop) because certain bit
| iteration is mishandled. In a number of places bitmaps are being used
| by the hypervisor to track certain state. Iteration over all bits
| involves functions which may misbehave in certain corner cases: On x86
| accesses to bitmaps with a compile time known size of 64 may incur
| undefined behavior, which may in particular result in infinite loops.
| A malicious guest may cause a hypervisor crash or hang, resulting in a
| Denial of Service (DoS). All versions of Xen are vulnerable. x86
| systems with 64 or more nodes are vulnerable (there might not be any
| such systems that Xen would run on). x86 systems with less than 64
| nodes are not vulnerable.


CVE-2019-19583[14]:
| An issue was discovered in Xen through 4.12.x allowing x86 HVM/PVH
| guest OS users to cause a denial of service (guest OS crash) because
| VMX VMEntry checks mishandle a certain case. Please see XSA-260 for
| background on the MovSS shadow. Please see XSA-156 for background on
| the need for #DB interception. The VMX VMEntry checks do not like the
| exact combination of state which occurs when #DB in intercepted,
| Single Stepping is active, and blocked by STI/MovSS is active, despite
| this being a legitimate state to be in. The resulting VMEntry failure
| is fatal to the guest. HVM/PVH guest userspace code may be able to
| crash the guest, resulting in a guest Denial of Service. All versions
| of Xen are affected. Only systems supporting VMX hardware virtual
| extensions (Intel, Cyrix, or Zhaoxin CPUs) are affected. Arm and AMD
| systems are unaffected. Only HVM/PVH guests are affected. PV guests
| cannot leverage the vulnerability.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-12207
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12207
[1] https://security-tracker.debian.org/tracker/CVE-2019-11135
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11135
[2] https://security-tracker.debian.org/tracker/CVE-2019-18420
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18420
[3] https://security-tracker.debian.org/tracker/CVE-2019-18421
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18421
[4] https://security-tracker.debian.org/tracker/CVE-2019-18422
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18422
[5] https://security-tracker.debian.org/tracker/CVE-2019-18423
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18423
[6] https://security-tracker.debian.org/tracker/CVE-2019-18424
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18424
[7] https://security-tracker.debian.org/tracker/CVE-2019-18425
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18425
[8] https://security-tracker.debian.org/tracker/CVE-2019-19577
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19577
[9] https://security-tracker.debian.org/tracker/CVE-2019-19578
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19578
[10] https://security-tracker.debian.org/tracker/CVE-2019-19579
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19579
[11] https://security-tracker.debian.org/tracker/CVE-2019-19580
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19580
[12] https://security-tracker.debian.org/tracker/CVE-2019-19581
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19581
[13] https://security-tracker.debian.org/tracker/CVE-2019-19582
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19582
[14] https://security-tracker.debian.org/tracker/CVE-2019-19583
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19583

Please adjust the affected versions in the BTS as needed.

Thanks for your work on the xen packages in Debian.

Regards,
Salvatore

Message #10 received at 947944@bugs.debian.org (full text, mbox, reply):

From: Hans van Kranenburg <hans@knorrie.org>

To: Salvatore Bonaccorso <carnil@debian.org>, 947944@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>

Subject: Re: Bug#947944: xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-2019-19579 CVE-2019-19580 CVE-2019-19581 CVE-2019-19582 CVE-2019-19583)

Date: Tue, 7 Jan 2020 23:34:55 +0100

Hi,

Today I have finally been working on this. The result is that I at least
have a new (WIP) version for buster. I'm running it on a dom0 right now
and did smoke testing, live migrate, restarting domUs etc. It just works
(tm).

This was the easy part, most of the work was assembling the changelog by
copy-pasting things. I cross-checked with your list (below), which is
nice, since we can check that way that the info from different points of
view is the same (except for one entry it is).

https://salsa.debian.org/xen-team/debian-xen/commits/knorrie/buster-security

Now the interesting part begins, which is not so much about the stable
security update, but more about what to do with unstable. We currently
still have the same Xen version in unstable and in Buster.

So, the most logical thing, which I mentioned before would be to have
4.11.3+24-g14b62ab3e5-1 in unstable and 4.11.3+24-g14b62ab3e5-1~deb10u1
in stable.

However... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938843
And on Dec 15, python-pyxenstore REMOVED from testing

So, I guess we're not supposed to upload something new to unstable that
includes this package again and/or uses python 2.

Also, we of course do not like a situation where the package in stable
has a newer version number than the one in unstable.

Checkmate...

We (as in, Debian Xen team, which is Ian and I who are currently active)
haven't been working on getting the latest greatest Xen into unstable
for Bullseye yet. The most recent Xen release (4.13) includes python3
support which fixes that issue, but getting that in means we have to
actively start working on newer packages now. This mostly means
reserving a few days to work on it, since it's not a really trivial
undertaking.

Another ducttape-option is to put the same thing in unstable again,
while stripping out python-pyxenstore from the control file, since it's
not a required package for the average usecase. Still, xen-utils-4.11
contains a bunch of python 2 files, which apparently are still under the
radar.

I'm thinking out loud here, and am curious about what you and Ian can
come up with.

On 1/2/20 3:57 PM, Salvatore Bonaccorso wrote:
> [...]
> 
> There are several CVEs open for xen up to unstable, compiling a list
> from the information from the security-tracker it looks those below.
> 
> Any progress in getting those fixed at least for unstable already?
> 
> CVE-2018-12207[0]:

check, XSA-304

> CVE-2019-11135[1]:

check, XAS-305

> CVE-2019-18420[2]:

check, XSA-296

> CVE-2019-18421[3]:

check, XSA-299

> CVE-2019-18422[4]:

check, XSA-303

> CVE-2019-18423[5]:

check, XSA-301

> CVE-2019-18424[6]:

check, XSA-302

> CVE-2019-18425[7]:

check, XSA-298

> CVE-2019-19577[8]:

check, XSA-311

> CVE-2019-19578[9]:

check, XSA-309

> CVE-2019-19579[10]:

check, XSA-306

> CVE-2019-19580[11]:

check, XSA-310

> CVE-2019-19581[12]:

check, XSA-307

> CVE-2019-19582[13]:

check, XSA-307

> CVE-2019-19583[14]:

check, XSA-308

In the changelog, I also have a fix for:
 XSA-295 CVE-2019-17349 CVE-2019-17350
 https://xenbits.xen.org/xsa/advisory-295.html

> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

I also added a commit to put in the CVE numbers in previous changelog
entries:

https://salsa.debian.org/xen-team/debian-xen/commit/0ee295f5caf6178f64febeb976d7ea968e44a191

Is this ok/wanted/great/what-you-like? Because, regularly, the numbers
are not available yet when we push out the update.

Thanks,
Hans van Kranenburg

Send a report that this bug log contains spam.