Information

Advisory

XSA-135

Public release

2015-06-10 13:10

Updated

2015-06-10 13:10

Version

3

CVE(s)

CVE-2015-3209

Title

Heap overflow in QEMU PCNET controller, allowing guest->host escape

Filesadvisory-135.txt (signed advisory file)
xsa135-qemut-1.patch
xsa135-qemut-2.patch
xsa135-qemuu-unstable.patch
xsa135-qemuu-4.2-1.patch
xsa135-qemuu-4.2-2.patch
xsa135-qemuu-4.3-1.patch
xsa135-qemuu-4.3-2.patch
xsa135-qemuu-4.5-1.patch
xsa135-qemuu-4.5-2.patchAdvisory

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

        Xen Security Advisory CVE-2015-3209 / XSA-135
                          version 3

Heap overflow in QEMU PCNET controller, allowing guest->host escape

UPDATES IN VERSION 3

Public release.

ISSUE DESCRIPTION

The QEMU security team has predisclosed the following advisory:

pcnet\_transmit loads a transmit-frame descriptor from the guest into the
/tmd/ local variable to recover a length field, a status field and a
guest-physical location of the associated frame buffer. If the status
field indicates that the frame buffer is ready to be sent out (i.e. by
setting the TXSTATUS\_DEVICEOWNS, TXSTATUS\_STARTPACKET and
TXSTATUS\_ENDPACKET bits on the status field), the PCNET device
controller pulls in the frame from the guest-physical location to
s->buffer (which is 4096 bytes long), and then transmits the frame.

Because of the layout of the transmit-frame descriptor, it is not
possible to send the PCNET device controller a frame of length > 4096,
but it /is/ possible to send the PCNET device controller a frame that is
marked as TXSTATUS\_STARTPACKET, but not TXSTATUS\_ENDPACKET. If we do
this - and the PCNET controller is configured via the XMTRL CSR to
support split-frame processing - then the pcnet\_transmit functions loops
round, pulling a second transmit frame descriptor from the guest. If
this second transmit frame descriptor sets the TXSTATUS\_DEVICEOWNS and
doesn't set the TXSTATUS\_STARTPACKET bits, this frame is appended to
the s->buffer field.

An attacker can then exploit this vulnerability by sending a first
packet of length 4096 to the device controller, and a second frame
containing N-bytes to trigger an N-byte heap overflow.

On 64-bit QEMU, a 24-byte overflow allows the guest to take control of
the phys\_mem\_write function pointer in the PCNetState\_st structure, and
this is called when trying to flush the updated transmit frame
descriptor back to the guest. By specifying the content of the second
transmit frame, the attacker therefore gets reliable fully-chosen
control of the host instruction pointer, allowing them to take control
of the host.

IMPACT

A guest which has access to an emulated PCNET network device (e.g. with “model=pcnet” in their VIF configuration) can exploit this vulnerability to take over the qemu process elevating its privilege to that of the qemu process.

VULNERABLE SYSTEMS

All Xen systems running x86 HVM guests without stubdomains which have been configured to use the PCNET emulated driver model are vulnerable.

The default configuration is NOT vulnerable (because it does not emulate PCNET NICs).

Systems running only PV guests are NOT vulnerable.

Systems using qemu-dm stubdomain device models (for example, by specifying “device_model_stubdomain_override=1” in xl’s domain configuration files) are NOT vulnerable.

Both the traditional “qemu-xen” or upstream qemu device models are potentially vulnerable.

ARM systems are NOT vulnerable.

MITIGATION

Avoiding the use of emulated network devices altogether, by specifying a PV only VIF in the domain configuration file will avoid this issue.

Avoiding the use of the PCNET device in favour of other emulations will also avoid this issue.

Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain.

qemu-dm stubdomains are only available with the traditional “qemu-xen” version.

CREDITS

This issue was discovered by Matt Tait of Google and reported to us via the QEMU security team.

RESOLUTION

Applying the appropriate attached patch(es) resolves this issue.

xsa135-qemuu-unstable.patch qemu-upstream, Xen unstable xsa135-qemuu-4.5-*.patch qemu-upstream, Xen 4.5.x, Xen 4.4.x xsa135-qemuu-4.3-*.patch qemu-upstream, Xen 4.3.x xsa135-qemuu-4.2-*.patch qemu-upstream, Xen 4.2.x xsa135-qemut-*.patch qemu-xen-traditional, Xen unstable, 4.5.x, 4.4.x, 4.3.x, 4.2.x

Note that the second patch for qemu-xen-traditional (all versions), and qemu-upstream 4.3.x and 4.2.x are identical. Likewise xsa135-qemuu-unstable.patch is the same as xsa135-qemuu-4.5-2.patch. They are presented separately for convenience.

$ sha256sum xsa135*.patch a40897166f5de84c11b5d547191cd0375c7052edb0f44940eec7b78d839e447b xsa135-qemut-1.patch d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091 xsa135-qemut-2.patch 099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da xsa135-qemuu-unstable.patch 12ca5521f6bb1227934a1711d8adee11138a84c080a217f250efe34b3cb25b10 xsa135-qemuu-4.2-1.patch d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091 xsa135-qemuu-4.2-2.patch ad32c0ac145bc02b901c061fcbef83965f443fe89fcae9efc3b1dfd1e1d70bc8 xsa135-qemuu-4.3-1.patch d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091 xsa135-qemuu-4.3-2.patch baf9e0a960693b246ff01bb6210c5fee7713999d1e1b00a5b4e29d9ebd3c0ce8 xsa135-qemuu-4.5-1.patch 099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da xsa135-qemuu-4.5-2.patch $

DEPLOYMENT DURING EMBARGO

Deployment of patches or mitigations is NOT permitted (except on systems used and administered only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted.

The decision not to permit deployment was made by the group that, at their discretion, disclosed the issue to the Xen Project Security Team.

Deployment is permitted only AFTER the embargo ends.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team’s decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community’s agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJVeDc3AAoJEIP+FMlX6CvZFBoIAJw/FxeABrdms6CzoxZxFQRp It9eoMcmP+cxjMuAJyO771s+wYZy/X+ZDM2+CmzDWdBOzst3/YVw0ePbNH1T86y6 23Miqm5zupJ30xQGIXledrd/S23tmRlmzylytJcI9UQktuAOnL50l+wovKwhxVtO x2Dg4P6RZ51twfbYLueIjBe2YSGGrck0kugpDtD6dH6kONNFgA+30i11Unwip18b FzKm54b5HIvSoOkXCggCdgaCOmAuz3LpAt7FfB1324dPblxlfrDyRxWABxn47qoL lgTJa7DPRTdxYM7EmnpMHKakgqzhD+Vu2Jnz8RELXt+AQH3TxRYXS2kT22QpfxY= =cx83 -----END PGP SIGNATURE-----

Xenproject.org Security Team