OracleVM 3.1 : xen (OVMSA-2013-0032)

medium Nessus Plugin ID 79503
New! Plugin Severity Now Using CVSS v3

The calculated severity for Plugins has been updated to use CVSS v3 by default. Plugins that do not have a CVSS v3 score will fall back to CVSS v2 for calculating severity. Severity display preferences can be toggled in the settings dropdown.

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 :

- defer event channel bucket pointer store until after XSM checks Otherwise a dangling pointer can be left, which would cause subsequent memory corruption as soon as the space got re-allocated for some other purpose. This is CVE-2013-1920 / XSA-47.

- x86: fix various issues with handling guest IRQs

- properly revoke IRQ access in map_domain_pirq error path

- don't permit replacing an in use IRQ

- don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI

- track IRQ access permission in host IRQ terms, not guest IRQ ones (and with that, also disallow Dom0 access to IRQ0) This is CVE-2013-1919 / XSA-46.

- x86: clear EFLAGS.NT in SYSENTER entry path ... as it causes problems if we happen to exit back via IRET: In the course of trying to handle the fault, the hypervisor creates a stack course of trying to handle the fault, the hypervisor creates a stack frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but expects to be able to IRET through that stack frame to the second portion of the fixup code (which causes a #GP due to the stored EFLAGS having NT set). And even if this worked (e.g if we cleared NT in that path), it would then (through the fail safe callback) cause a #GP in the guest with the SYSENTER handler's first instruction as the source, which in turn would allow guest user mode code to crash the guest kernel. Inject a #GP on the fake (NULL) address of the SYSENTER instruction instead, just like in the case where the guest kernel didn't register a corresponding entry point. On 32-bit we also need to make sure we clear SYSENTER_CS for all CPUs (neither #RESET nor #INIT guarantee this). This is CVE-2013-1917 / XSA-44. (CVE-2013-1917)

- Current Xend allowing multiple call destroy for the same domain, this lead multiple hard resets(FLR) for pci pass-through, and some controller might failed. In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, after guest brought up, call xm-destroy twice, the adapters's BIOS will hung, and we had to reboot the server to recovery it. BTW: I had send this patch to Xen maillist, but developer said Xend will obsolete and would not review and merge the fix.

Solution

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

See Also

http://www.nessus.org/u?316f37b9

Plugin Details

Severity: Medium

ID: 79503

File Name: oraclevm_OVMSA-2013-0032.nasl

Version: 1.4

Type: local

Published: 11/26/2014

Updated: 1/4/2021

Dependencies: ssh_get_info.nasl

Risk Information

VPR

Risk Factor: Medium

Score: 5.9

CVSS v2

Risk Factor: Medium

Base Score: 4.7

Temporal Score: 4.1

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

Temporal Vector: E:ND/RL:OF/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.1

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

Exploit Ease: No known exploits are available

Patch Publication Date: 4/22/2013

Vulnerability Publication Date: 4/12/2013

Reference Information

CVE: CVE-2013-1917, CVE-2013-1919, CVE-2013-1920

BID: 58880, 59291, 59292