OracleVM 3.2 : xen (OVMSA-2018-0225)

high Nessus Plugin ID 110305

Synopsis

The remote OracleVM host is missing one or more security updates.

Description

The remote OracleVM system is missing necessary patches to address critical security updates :

- From: Jan Beulich Subject: x86/paging: don't unconditionally BUG on finding SHARED_M2P_ENTRY PV guests can fully control the values written into the P2M. This is XSA-251. (CVE-2017-17565)

- From: Jan Beulich Subject: x86/shadow: fix ref-counting error handling The old-Linux handling in shadow_set_l4e mistakenly ORed together the results of sh_get_ref and sh_pin. As the latter failing is not a correctness problem, simply ignore its return value. In sh_set_toplevel_shadow a failing sh_get_ref must not be accompanied by installing the entry, despite the domain being crashed. This is XSA-250. (CVE-2017-17564)

- From: Jan Beulich Subject: x86/shadow: fix refcount overflow check Commit c385d27079 ('x86 shadow: for multi-page shadows, explicitly track the first page') reduced the refcount width to 25, without adjusting the overflow check. Eliminate the disconnect by using a manifest constant. Interestingly, up to commit 047782fa01 ('Out-of-sync L1 shadows: OOS snapshot') the refcount was 27 bits wide, yet the check was already using 26. This is XSA-249. v2: Simplify expression back to the style it was. (CVE-2017-17563)

- From: Jan Beulich Subject: x86/mm: don't wrongly set page ownership PV domains can obtain mappings of any pages owned by the correct domain, including ones that aren't actually assigned as 'normal' RAM, but used by Xen internally. At the moment such 'internal' pages marked as owned by a guest include pages used to track logdirty bits, as well as p2m pages and the 'unpaged pagetable' for HVM guests. Since the PV memory management and shadow code conflict in their use of struct page_info fields, and since shadow code is being used for log-dirty handling for PV domains, pages coming from the shadow pool must, for PV domains, not have the domain set as their owner. While the change could be done conditionally for just the PV case in shadow code, do it unconditionally (and for consistency also for HAP), just to be on the safe side. There's one special case though for shadow code: The page table used for running a HVM guest in unpaged mode is subject to get_page (in set_shadow_status) and hence must have its owner set. This is XSA-248.

Conflict: xen/arch/x86/mm/hap/hap.c xen/arch/x86/mm/shadow/common.c (CVE-2017-17566)

Solution

Update the affected xen / xen-devel / xen-tools packages.

See Also

https://oss.oracle.com/pipermail/oraclevm-errata/2018-June/000860.html

Plugin Details

Severity: High

ID: 110305

File Name: oraclevm_OVMSA-2018-0225.nasl

Version: 1.3

Type: local

Published: 6/4/2018

Updated: 9/27/2019

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: Medium

Score: 6.5

CVSS v2

Risk Factor: Medium

Base Score: 6.9

Temporal Score: 5.1

Vector: CVSS2#AV:L/AC:M/Au:N/C:C/I:C/A:C

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 6.8

Vector: CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

CPE: p-cpe:/a:oracle:vm:xen, p-cpe:/a:oracle:vm:xen-devel, p-cpe:/a:oracle:vm:xen-tools, cpe:/o:oracle:vm_server:3.2

Required KB Items: Host/local_checks_enabled, Host/OracleVM/release, Host/OracleVM/rpm-list

Exploit Ease: No known exploits are available

Patch Publication Date: 6/1/2018

Vulnerability Publication Date: 12/12/2017

Reference Information

CVE: CVE-2017-17563, CVE-2017-17564, CVE-2017-17565, CVE-2017-17566