Bug 851252 (CVE-2012-3515)

Summary: CVE-2012-3515 qemu: VT100 emulation vulnerability
Product: [Other] Security Response Reporter: Petr Matousek <pmatouse>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: acathrow, areis, armbru, berrange, bsarathy, drjones, ehabkost, gcy3y, imammedo, knoel, leiwang, lersek, michen, minovotn, mkenneth, mrezanin, pbonzini, rcvalle, rhod, security-response-team, tburke, virt-maint, xen-maint, xwei
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-24 14:07:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 851253, 851254, 851255, 851256, 851257, 851258, 854599, 854600, 854854    
Bug Blocks: 851264, 853908, 853917, 853920, 854054    

Description Petr Matousek 2012-08-23 15:13:36 UTC
A flaw has been found in the way qemu handles VT100 escape sequences when emulating certain devices with a virtual console backend.

An attacker who has sufficient privilege to access a vulnerable device within a guest can overwrite portions qemu address space. This can allow them to escalate their privileges to that of the qemu process on the host.

Acknowledgements:

Red Hat would like to thank the Xen project for reporting this issue.

Comment 1 Petr Matousek 2012-08-23 15:15:48 UTC
Xen
===

All hosts running HVM guests are potentially vulnerable to this depending on the specific guest configuration. The default configuration is not vulnerable.

When using libvirt, the default configuration of managed guests is safe, too. Libvirt by default configures the serial and parallel ports in a way that is not vulnerable.

Please note that configuring serial and/or parallel port to use vc backend later, makes the host vulnerable even when libvirt is used to manage the guest.

PV guests are not affected by this issue.

Comment 2 Petr Matousek 2012-08-23 15:17:04 UTC
KVM
===

All hosts running KVM guests are potentially vulnerable to this depending on the specific guest configuration. The default configuration is not vulnerable.

The only supported way of running qemu-kvm on Red Hat Enterprise Linux 5 is using libvirt. When guest is created, libvirt by default configures the serial and parallel ports in a way that is not vulnerable.

Please note that configuring serial and/or parallel port to use vc backend later, makes the host vulnerable even when libvirt is used to manage the guest.

Running qemu-kvm directly from command line can potentially make the system vulnerable.


On Red Hat Enterprise Linux 6, command line execution of qemu-kvm is supported provided that "-nodefaults" parameter is passed in as one of the arguments. Using "-nodefaults" disables default insecure configuration. For further information please refer to [1]. As long as "-nodefaults" argument is passed in and serial and/or parallel port is not configured to use vc backend, the host is not vulnerable.

  [1] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/ch19s10.html

When guest is created, libvirt by default configures the serial and parallel ports in a way that is not vulnerable.

Please note that configuring serial and/or parallel port to use vc backend later, makes the host vulnerable even when libvirt is used to manage the guest.

Comment 6 Petr Matousek 2012-08-23 15:22:17 UTC
Statement:

This issue did affect the versions of xen package as shipped with Red Hat
Enterprise Linux 5.

This issue did affect the versions of kvm package as shipped with Red Hat
Enterprise Linux 5.

This issue did affect the versions of qemu-kvm package as shipped with Red Hat
Enterprise Linux 6.

Comment 17 Petr Matousek 2012-09-05 12:07:34 UTC
Now public via:

http://seclists.org/oss-sec/2012/q3/381

Comment 18 Petr Matousek 2012-09-05 12:10:00 UTC
Created xen tracking bugs for this issue

Affects: fedora-all [bug 854599]

Comment 19 Petr Matousek 2012-09-05 12:10:08 UTC
Created qemu tracking bugs for this issue

Affects: fedora-all [bug 854600]

Comment 20 errata-xmlrpc 2012-09-05 16:36:58 UTC
This issue has been addressed in following products:

  RHEV-H and Agents for RHEL-6

Via RHSA-2012:1233 https://rhn.redhat.com/errata/RHSA-2012-1233.html

Comment 21 errata-xmlrpc 2012-09-05 16:47:25 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:1235 https://rhn.redhat.com/errata/RHSA-2012-1235.html

Comment 22 errata-xmlrpc 2012-09-05 16:49:58 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2012:1234 https://rhn.redhat.com/errata/RHSA-2012-1234.html

Comment 23 errata-xmlrpc 2012-09-05 16:58:03 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:1236 https://rhn.redhat.com/errata/RHSA-2012-1236.html

Comment 24 errata-xmlrpc 2012-09-13 16:52:00 UTC
This issue has been addressed in following products:

  RHEV-H, V2V and Agents for RHEL-5

Via RHSA-2012:1262 https://rhn.redhat.com/errata/RHSA-2012-1262.html

Comment 25 Fedora Update System 2012-09-17 18:00:28 UTC
xen-4.1.3-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 errata-xmlrpc 2012-10-02 17:11:22 UTC
This issue has been addressed in following products:

  RHEV-H and Agents for RHEL-6

Via RHSA-2012:1325 https://rhn.redhat.com/errata/RHSA-2012-1325.html

Comment 27 gcy3y 2012-11-25 08:12:06 UTC
are there any test code for this. thank you!

Comment 30 Petr Matousek 2012-11-26 16:18:30 UTC
Hello,

(In reply to comment #27)
> are there any test code for this. thank you!

I am sorry but we do not share security issues reproducers.

Best regards,
--
Petr Matousek / Red Hat Security Response Team