OracleVM 3.0 : xen (OVMSA-2012-0056)

This script is Copyright (C) 2014-2017 Tenable Network Security, Inc.


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 :

- xen: fix error handling of
guest_physmap_mark_populate_on_demand The only user of
the 'out' label bypasses a necessary unlock, thus
enabling the caller to lock up Xen. Also, the function
was never meant to be called by a guest for itself, so
rather than inspecting the code paths in depth for
potential other problems this might cause, and adjusting
e.g. the non-guest printk in the above error path, just
disallow the guest access to it. Finally, the printk
(considering its potential of spamming the log, the more
that it's not using XENLOG_GUEST), is being converted to
P2M_DEBUG, as debugging is what it apparently was added
for in the first place. This is XSA-30 / CVE-2012-5514.
(CVE-2012-5514)

- Revert version 2 of XSA-30 / CVE-2012-5514
(CVE-2012-5514)

- memop: limit guest specified extent order Allowing
unbounded order values here causes almost unbounded
loops and/or partially incomplete requests, particularly
in PoD code. The added range checks in populate_physmap,
decrease_reservation, and the 'in' one in
memory_exchange architecturally all could use PADDR_BITS
- PAGE_SHIFT, and are being artificially constrained to
MAX_ORDER. This is XSA-31 / CVE-2012-5515.
(CVE-2012-5515)

- xen: fix error path of
guest_physmap_mark_populate_on_demand The only user of
the 'out' label bypasses a necessary unlock, thus
enabling the caller to lock up Xen. This is XSA-30 /
CVE-2012-5514. (CVE-2012-5514)

- xen: add missing guest address range checks to
XENMEM_exchange handlers Ever since its existence (3.0.3
iirc) the handler for this has been using non address
range checking guest memory accessors (i.e. the ones
prefixed with two underscores) without first range
checking the accessed space (via guest_handle_okay),
allowing a guest to access and overwrite hypervisor
memory. This is XSA-29 / CVE-2012-5513.

- hvm: Limit the size of large HVM op batches Doing large
p2m updates for HVMOP_track_dirty_vram without
preemption ties up the physical processor. Integrating
preemption into the p2m updates is hard so simply limit
to 1GB which is sufficient for a 15000 * 15000 * 32bpp
framebuffer. For HVMOP_modified_memory and
HVMOP_set_mem_type preemptible add the necessary
machinery to handle preemption. This is CVE-2012-5511 /
XSA-27.

x86/paging: Don't allocate user-controlled amounts of
stack memory. This is XSA-27 / CVE-2012-5511.

v2: Provide definition of GB to fix x86-32 compile.

- xen/common/grant_table.c gnttab: fix releasing of memory
upon switches between versions
gnttab_unpopulate_status_frames incompletely freed the
pages previously used as status frame in that they did
not get removed from the domain's xenpage_list, thus
causing subsequent list corruption when those pages did
get allocated again for the same or another purpose.
Similarly, grant_table_create and gnttab_grow_table both
improperly clean up in the event of an error - pages
already shared with the guest can't be freed by just
passing them to free_xenheap_page. Fix this by sharing
the pages only after all allocations succeeded. This is
CVE-2012-5510 / XSA-26. (CVE-2012-5510)

See also :

http://www.nessus.org/u?7261a1be

Solution :

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

Risk factor :

Medium / CVSS Base Score : 6.9
(CVSS2#AV:L/AC:M/Au:N/C:C/I:C/A:C)
CVSS Temporal Score : 6.0
(CVSS2#E:ND/RL:OF/RC:C)
Public Exploit Available : false

Family: OracleVM Local Security Checks

Nessus Plugin ID: 79490 ()

Bugtraq ID: 56794
56796
56797
56798
56803

CVE ID: CVE-2012-5510
CVE-2012-5511
CVE-2012-5513
CVE-2012-5514
CVE-2012-5515

Ready to Amp Up Your Nessus Experience?

Get Nessus Professional to scan unlimited IPs, run compliance checks & more

Buy Nessus Professional Now