This script is Copyright (C) 2014-2017 Tenable Network Security, Inc.
The remote OracleVM host is missing one or more security updates.
The remote OracleVM system is missing necessary patches to address
critical security updates :
- x86: fix page refcount handling in page table pin error
path In the original patch 7 of the series addressing
XSA-45 I mistakenly took the addition of the call to
get_page_light in alloc_page_type to cover two
decrements that would happen: One for the PGT_partial
bit that is getting set along with the call, and the
other for the page reference the caller hold (and would
be dropping on its error path). But of course the
additional page reference is tied to the PGT_partial
bit, and hence any caller of a function that may leave
->arch.old_guest_table non-NULL for error cleanup
purposes has to make sure a respective page reference
gets retained. Similar issues were then also spotted
elsewhere: In effect all callers of
get_page_type_preemptible need to deal with errors in
similar ways. To make sure error handling can work this
way without leaking page references, a respective
assertion gets added to that function. This is
CVE-2013-1432 / XSA-58.
- libxl: Restrict permissions on PV console device
xenstore nodes Matthew Daley has observed that the PV
console protocol places sensitive host state into a
guest writeable xenstore locations, this includes :
- The pty used to communicate between the console backend
daemon and its client, allowing the guest administrator
to read and write arbitrary host files.
- The output file, allowing the guest administrator to
write arbitrary host files or to target arbitrary qemu
chardevs which include sockets, udp, ptr, pipes etc (see
-chardev in qemu(1) for a more complete list).
- The maximum buffer size, allowing the guest
administrator to consume more resources than the host
administrator has configured.
- The backend to use (qemu vs xenconsoled), potentially
allowing the guest administrator to confuse host
software. So we arrange to make the sensitive keys in
the xenstore frontend directory read only for the guest.
This is safe since the xenstore permissions model,
unlike POSIX directory permissions, does not allow the
guest to remove and recreate a node if it has write
access to the containing directory. There are a few
associated wrinkles :
- The primary PV console is 'special'. It's xenstore node
is not under the usual /devices/ subtree and it does not
use the customary xenstore state machine protocol.
Unfortunately its directory is used for other things,
including the vnc-port node, which we do not want the
guest to be able to write to. Rather than trying to
track down all the possible secondary uses of this
directory just make it r/o to the guest. All newly
created subdirectories inherit these permissions and so
are now safe by default.
- The other serial consoles do use the customary xenstore
state machine and therefore need write access to at
least the 'protocol' and 'state' nodes, however they may
also want to use arbitrary 'feature-foo' nodes (although
I'm not aware of any) and therefore we cannot simply
lock down the entire frontend directory. Instead we add
support to libxl__device_generic_add for frontend keys
which are explicitly read only and use that to lock down
the sensitive keys.
- Minios' console frontend wants to write the 'type' node,
which it has no business doing since this is a
host/toolstack level decision. This fails now that the
node has become read only to the PV guest. Since the
toolstack already writes this node just remove the
attempt to set it. This is CVE-XXXX-XXX / XSA-57
Conflicts (4.2 backport): tools/libxl/libxl.c (no vtpm,
free front_ro on error in libxl__device_console_add)
Conflicts (4.1 backport):
- minios code was in xencons_ring.c
- many places need &gc not just gc
- libxl__xs_writev path is not const
- varios minor context fixups
See also :
Update the affected xen / xen-devel / xen-tools packages.
Risk factor :
High / CVSS Base Score : 7.4
CVSS Temporal Score : 6.4
Public Exploit Available : false