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.
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.
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.
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.
Now public via: http://seclists.org/oss-sec/2012/q3/381
Created xen tracking bugs for this issue Affects: fedora-all [bug 854599]
Created qemu tracking bugs for this issue Affects: fedora-all [bug 854600]
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
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
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
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
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
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.
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
are there any test code for this. thank you!
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