+++ This bug was initially created as a clone of Bug #21826 +++ openSUSE has issued an advisory on October 6 (bsc#1053600): https://lists.opensuse.org/opensuse-updates/2017-10/msg00018.html Debian has issued an advisory on October 19 (CVE-2017-1000256): https://www.debian.org/security/2017/dsa-4003 Upstream advisory for the second issue (October 16): https://security.libvirt.org/2017/0002.html Patches have been checked into Mageia 6 SVN, but an update has not been able to be issued yet because the package doesn't build, due to a test suite failure. This needs to be fixed or we will be unable to support this package on Mageia 6. Saving the advisory for later. Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=14192#c7 Advisory: ======================== Updated libvirt packages fix security vulnerabilities: In virsh, the hostname could crafted maliciously with ssh arguments, which would be passed to ssh (bsc#1053600). The default_tls_x509_verify (and related) parameters in qemu.conf control whether the TLS servers in QEMU request & verify certificates from clients. This works as a simple access control system for QEMU servers by requiring the CA to issue certs to permitted clients. This use of client certificates is disabled by default, since it requires extra work to issue client certificates. Unfortunately the libvirt code was using these configuration parameters when setting up both TLS clients and servers in QEMU. The result was that TLS clients for character devices and disk devices had verification turned off, meaning they would ignore any errors while validating the server certificate (CVE-2017-1000256). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000256 https://security.libvirt.org/2017/0002.html https://lists.opensuse.org/opensuse-updates/2017-10/msg00018.html https://lists.opensuse.org/opensuse-updates/2017-10/msg00096.html ======================== Updated packages in core/updates_testing: ======================== libvirt-docs-3.3.0-1.1.mga6 libvirt0-3.3.0-1.1.mga6 libvirt-devel-3.3.0-1.1.mga6 libvirt-utils-3.3.0-1.1.mga6 wireshark-libvirt-3.3.0-1.1.mga6 from libvirt-3.3.0-1.1.mga6.src.rpm
We should add in CVE-2017-5715 mitigations too, like RedHat: https://access.redhat.com/errata/RHSA-2018:0029
As tmb has mentioned in a QA meeting, we should probably just update this to a newer version. RHEL 7.5 will update it to 3.9.0 to fix this issue and deal with CVE-2017-5715 (Spectre).
CC: (none) => tmb
openSUSE has issued an advisory today (February 1): https://lists.opensuse.org/opensuse-updates/2018-01/msg00120.html It fixes a new issue, CVE-2018-5748.
Summary: libvirt new security issues (one fixed upstream, plus CVE-2017-1000256) => libvirt new security issues (one fixed upstream, plus CVE-2017-1000256 and CVE-2018-5748)
Status comment: (none) => Should probably be updated as it won't build anyway
New version 3.10.0 fixes the build failure noted in the description above. The original advisory should still apply with the following changes in the file list. lib64virt0-3.10.0-1.mga6 lib64virt-devel-3.10.0-1.mga6 libvirt-docs-3.10.0-1.mga6 libvirt-utils-3.10.0-1.mga6 wireshark-libvirt-3.10.0-1.mga6 from libvirt-3.10.0-1.mga6.src.rpm
CC: (none) => mramboAssignee: pkg-bugs => qa-bugs
There should also be some mention in the advisory of the Spectre mitigations. You can probably copy it from the Red Hat advisory (and add that to the References).
Revised Advisory: ======================== Updated libvirt packages fix security vulnerabilities: In virsh, the hostname could crafted maliciously with ssh arguments, which would be passed to ssh (bsc#1053600). The default_tls_x509_verify (and related) parameters in qemu.conf control whether the TLS servers in QEMU request & verify certificates from clients. This works as a simple access control system for QEMU servers by requiring the CA to issue certs to permitted clients. This use of client certificates is disabled by default, since it requires extra work to issue client certificates. Unfortunately the libvirt code was using these configuration parameters when setting up both TLS clients and servers in QEMU. The result was that TLS clients for character devices and disk devices had verification turned off, meaning they would ignore any errors while validating the server certificate (CVE-2017-1000256). An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks (CVE-2017-5715). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000256 https://security.libvirt.org/2017/0002.html https://lists.opensuse.org/opensuse-updates/2017-10/msg00018.html https://lists.opensuse.org/opensuse-updates/2017-10/msg00096.html https://access.redhat.com/errata/RHSA-2018:0029 ======================== Updated packages in core/updates_testing: ======================== lib64virt0-3.10.0-1.mga6 lib64virt-devel-3.10.0-1.mga6 libvirt-docs-3.10.0-1.mga6 libvirt-utils-3.10.0-1.mga6 wireshark-libvirt-3.10.0-1.mga6 from libvirt-3.10.0-1.mga6.src.rpm
I have already running qemu-kvm and virt-manager with both Mageia 6 x86_64 as host and client. Network interface is bridge, enp14s0:macvtap. Everything is working fine, no regression found. I installed a Fedora 27 VM from a fresh qcow2-file. No problems found. I did not test virsh,though. I am not familiar with virsh, and the testing procedure does not require virsh. Installed packages lib64virt0-3.10.0-1.mga6 lib64virt-glib1.0_0-0.2.3-2.mga6 lib64virt-glib-gir1.0-0.2.3-2.mga6 libvirt-utils-3.10.0-1.mga6 python-libvirt-3.3.0-1.mga6 virt-manager-1.4.1-1.mga6 virt-manager-common-1.4.1-1.mga6 Ulrich
The fix for CVE-2018-5748 has not been included with this update, and there's an additional issue CVE-2018-6764. Ubuntu has issued an advisory for this on February 20: https://usn.ubuntu.com/usn/usn-3576-1/
Summary: libvirt new security issues (one fixed upstream, plus CVE-2017-1000256 and CVE-2018-5748) => libvirt new security issues (one fixed upstream, plus CVE-2017-1000256, CVE-2018-5748 and CVE-2018-6764)Assignee: qa-bugs => mramboCC: (none) => qa-bugsStatus comment: Should probably be updated as it won't build anyway => (none)CVE: CVE-2017-1000256 => (none)
Status comment: (none) => Upstream patches are available
Don't forget, we'll need to update python-libvirt too.
Revised Advisory: ======================== Updated libvirt packages fix security vulnerabilities: In virsh, the hostname could crafted maliciously with ssh arguments, which would be passed to ssh (bsc#1053600). The default_tls_x509_verify (and related) parameters in qemu.conf control whether the TLS servers in QEMU request & verify certificates from clients. This works as a simple access control system for QEMU servers by requiring the CA to issue certs to permitted clients. This use of client certificates is disabled by default, since it requires extra work to issue client certificates. Unfortunately the libvirt code was using these configuration parameters when setting up both TLS clients and servers in QEMU. The result was that TLS clients for character devices and disk devices had verification turned off, meaning they would ignore any errors while validating the server certificate (CVE-2017-1000256). An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks (CVE-2017-5715). qemu/qemu_monitor.c in libvirt allows attackers to cause a denial of service (memory consumption) via a large QEMU reply (CVE-2018-5748). It was discovered libvirt does not properly determine the hostname on LXC container startup, which allows local guest OS users to bypass an intended container protection mechanism and execute arbitrary commands via a crafted NSS module (CVE-2018-6764). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000256 https://security.libvirt.org/2017/0002.html https://lists.opensuse.org/opensuse-updates/2017-10/msg00018.html https://lists.opensuse.org/opensuse-updates/2017-10/msg00096.html https://access.redhat.com/errata/RHSA-2018:0029 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5748 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6764 ======================== Updated packages in core/updates_testing: ======================== lib64virt0-3.10.0-1.1.mga6 lib64virt-devel-3.10.0-1.1.mga6 libvirt-docs-3.10.0-1.1.mga6 libvirt-utils-3.10.0-1.1.mga6 wireshark-libvirt-3.10.0-1.1 from libvirt-3.10.0-1.1.mga6.src.rpm Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=14192#c7 A matching version update for python-libvirt was done as a part of the libvirt security update. Updated packages in core/updates_testing: ======================== python3-libvirt-3.10.0-1.mga6 python-libvirt-3.10.0-1.mga6 from python-libvirt-3.10.0-1.mga6.src.rpm
Assignee: mrambo => qa-bugs
Advisory from comment 10 uploaded.
Keywords: (none) => advisory
Installed packages lib64virt0-3.10.0-1.1.mga6 lib64virt-glib1.0_0-0.2.3-2.mga6 lib64virt-glib-gir1.0-0.2.3-2.mga6 libvirt-utils-3.10.0-1.1.mga6 python-libvirt-3.10.0-1.mga6 virt-manager-1.4.1-1.mga6 virt-manager-common-1.4.1-1.mga6 I found now a small regression: Copy & paste does not work with a Plasma client and spice-gtk. Host has Plasma 5.11.95, client has Plasma 5.12.2. Another client under Gnome is working fine, so it is a Plasma issue and does not hinder to mark the test as ok. Ulrich
Whiteboard: (none) => mga6-64-ok
Validating the update based on comment 12
Keywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0153.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED