openSUSE has issued an advisory on October 6: https://lists.opensuse.org/opensuse-updates/2017-10/msg00018.html Mageia 5 may also be affected.
No registered maintainer, so assigning to all packagers collectively.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
CC: (none) => bequimao.de
Daniel P. Berrange reported that Libvirt, a virtualisation abstraction library, does not properly handle the default_tls_x509_verify (and related) parameters in qemu.conf when setting up TLS clients and servers in QEMU, resulting in TLS clients for character devices and disk devices having verification turned off and ignoring any errors while validating the server certificate.
CC: (none) => zombie_ryushuCVE: (none) => CVE-2017-1000256URL: (none) => https://www.debian.org/security/2017/dsa-4003
Summary: libvirt new security issue fixed upstream => libvirt new security issue fixed upstream CVE-2017-1000256
Zombie, please be careful. The DSA issue is different than the one from openSUSE that I originally reported on this bug. Debian advisory for the new issue (October 19): https://www.debian.org/security/2017/dsa-4003 Upstream advisory for the new issue (October 16): https://security.libvirt.org/2017/0002.html
Summary: libvirt new security issue fixed upstream CVE-2017-1000256 => libvirt new security issues (one fixed upstream, plus CVE-2017-1000256)
Patch package uploaded for Mageia 5. Patched checked into Mageia 6 SVN, but it doesn't build because a test fails: http://pkgsubmit.mageia.org/uploads/failure/6/core/updates_testing/20171110235652.luigiwalser.duvel.16519/log/libvirt-3.3.0-1.1.mga6/build.0.20171110235702.log Saving 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). Note that the CVE-2017-1000256 issue only affected Mageia 6. 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: ======================== libvirt0-1.2.9.3-1.5.mga5 libvirt-devel-1.2.9.3-1.5.mga5 libvirt-utils-1.2.9.3-1.5.mga5 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 SRPMS: libvirt-1.2.9.3-1.5.mga5.src.rpm libvirt-3.3.0-1.1.mga6.src.rpm
Keywords: (none) => has_procedureWhiteboard: (none) => MGA5TOOURL: https://www.debian.org/security/2017/dsa-4003 => (none)
Split non-buildable Mageia 6 package to Bug 22280. 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). References: https://lists.opensuse.org/opensuse-updates/2017-10/msg00018.html ======================== Updated packages in core/updates_testing: ======================== libvirt0-1.2.9.3-1.5.mga5 libvirt-devel-1.2.9.3-1.5.mga5 libvirt-utils-1.2.9.3-1.5.mga5 libvirt-docs-3.3.0-1.1.mga6 from libvirt-1.2.9.3-1.5.mga5.src.rpm
CVE: CVE-2017-1000256 => (none)Source RPM: libvirt-3.3.0-1.mga6.src.rpm => libvirt-1.2.9.3-1.4.mga5.src.rpmAssignee: pkg-bugs => qa-bugsWhiteboard: MGA5TOO => (none)Version: 6 => 5
MGA5-32 on Dell Latitude D600 Xfce No installation issues To run the procedure as above, virt-manager needs to be installed additionally. Then # systemctl start libvirtd # systemctl -l status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since zo 2017-12-31 10:22:22 CET; 18s ago Docs: man:libvirtd(8) http://libvirt.org Main PID: 5684 (libvirtd) CGroup: /system.slice/libvirtd.service ├─5684 /usr/sbin/libvirtd ├─5754 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper └─5755 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper Seems OK As normal user $ virt-manager getting no feedback on CLI, window opens and displays (short translation) Cannot detect standard hypervisor. Make sure the correct packages kvm, qemu, libvirt are installed and the libvirt service is running. I am not inclined to install kvm and/or qemu on this already overloaded laptop. Quitting.
CC: (none) => herman.viaene
CC: (none) => davidwhodginsKeywords: (none) => advisory
on mga5-64 # rpm -q qemu qemu-img virt-manager libvirt-utils lib64virt0 qemu-2.4.1-7.mga5 qemu-img-2.4.1-7.mga5 virt-manager-1.1.0-7.mga5 libvirt-utils-1.2.9.3-1.5.mga5 lib64virt0-1.2.9.3-1.5.mga5 There is no libvirt-docs package in mga5. That was the case prior to this update - so this is not a regression. # systemctl status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Mon 2018-01-01 10:01:45 GMT; 17s ago # virsh capabilities Displays host and guest capabilities Used virt-manager to create a VM and boot an iso, following the steps I described in https://bugs.mageia.org/show_bug.cgi?id=17417#c38 OK for mga5-64
CC: (none) => jimWhiteboard: (none) => MGA5-64-OK
On mga5-32 (in a vbox VM) # rpm -q qemu qemu-img virt-manager libvirt-utils libvirt0 qemu-2.4.1-7.mga5 qemu-img-2.4.1-7.mga5 virt-manager-1.1.0-7.mga5 libvirt-utils-1.2.9.3-1.5.mga5 libvirt0-1.2.9.3-1.5.mga5 # systemctl start libvirtd # systemctl status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Mon 2018-01-01 11:13:31 GMT; 3s ago # virsh capabilities Displays capabilities of host and guests Used virt-manager to create a VM and boot an iso OK for mga5-32
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK
This update is now validated and can be pushed to updates.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0017.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
except since installing i can no longer connect to my connection using virtual machine manager, the dialogue box gives the folowing error: Unable to connect to libvirt. internal error: Cannot find suitable emulator for x86_64 and expanding for details: nable to connect to libvirt. internal error: Cannot find suitable emulator for x86_64 Libvirt URI is: qemu:///system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 977, in _open_thread self._populate_initial_state() File "/usr/share/virt-manager/virtManager/connection.py", line 939, in _populate_initial_state logging.debug("conn version=%s", self._backend.conn_version()) File "/usr/share/virt-manager/virtinst/connection.py", line 316, in conn_version self._conn_version = self._libvirtconn.getVersion() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3697, in getVersion if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self) libvirtError: internal error: Cannot find suitable emulator for x86_64 is there another package that needs to be updated to match? bascule(In reply to Mageia Robot from comment #10) > An update for this issue has been pushed to the Mageia Updates repository. > > https://advisories.mageia.org/MGASA-2018-0017.html (In reply to Mageia Robot from comment #10) > An update for this issue has been pushed to the Mageia Updates repository. > > https://advisories.mageia.org/MGASA-2018-0017.html
CC: (none) => asura
(In reply to bascule teller from comment #11) > except since installing i can no longer connect to my connection using > virtual machine manager, the dialogue box gives the folowing error: > > Unable to connect to libvirt. > > internal error: Cannot find suitable emulator for x86_64 > Dis you restart libvirtd after the update (if it didn't get triggered on update)
CC: (none) => tmb
(In reply to Thomas Backlund from comment #12) > > > > Dis you restart libvirtd after the update (if it didn't get triggered on > update) yes, several reboots in fact, i've also checked that i'm up to date on all packages which 'urpmi --auto-update' tells me i am
What qemu version ?
And is there any errors in the logs?
qemu-2.4.1-5.mga5 logs wise: libvirtd.log warning : virQEMUCapsLogProbeFailure:3360 : Failed to probe capabilities for /usr/bin/qemu-system-sparc: unsupported configuration: QEMU 2.4.1 is too new for help parsing 2018-01-03 16:06:45.138+0000: 9659: error : qemuMonitorOpenUnix:309 : failed to connect to monitor socket: No such process 2018-01-03 16:06:45.153+0000: 9659: error : virQEMUCapsParseHelpStr:1391 : unsupported configuration: QEMU 2.4.1 is too new for help parsing 2018-01-03 16:06:45.153+0000: 9659: warning : virQEMUCapsLogProbeFailure:3360 : Failed to probe capabilities for /usr/bin/qemu-system-x86_64: unsupported configuration: QEMU 2.4.1 is too new for help parsing 2018-01-03 16:06:45.354+0000: 9659: error : qemuMonitorOpenUnix:309 : failed to connect to monitor socket: No such process 2018-01-03 16:06:45.367+0000: 9659: error : virQEMUCapsParseHelpStr:1391 : unsupported configuration: QEMU 2.4.1 is too new for help parsing 2018-01-03 16:06:45.367+0000: 9659: warning : virQEMUCapsLogProbeFailure:3360 : Failed to probe capabilities for /usr/bin/qemu-kvm: unsupported configuration: QEMU 2.4.1 is too new for help parsing 2018-01-03 16:06:45.368+0000: 9659: error : virQEMUCapsGetDefaultVersion:1852 : internal error: Cannot find suitable emulator for x86_64 any other logs you need? if this is just me and everyone else has continued functionality then i guess i'll just have to assume that co-incidentally something else changed since my system updated this morning (been away)
qemu-2.4.1-7.mga5 must have been in testing and I must have failed to disable the testing repo before installing qemu. I did check that there was no pending update bug for qemu, but did not check the repo. I'll downgrade qemu to qemu-2.4.1-5.mga5 and re-test, but that will be tomorrow at the earliest.
If it turns out that this was dependent on that qemu build, maybe we can re-push qemu to the build system and move it to updates. It fixed a bunch of security issues anyway.
re-testing on mga5-64 with the released version of qemu $ rpm -q qemu qemu-img virt-manager libvirt-utils lib64virt0 qemu-2.4.1-5.mga5 qemu-img-2.4.1-5.mga5 virt-manager-1.1.0-7.mga5 libvirt-utils-1.2.9.3-1.5.mga5 lib64virt0-1.2.9.3-1.5.mga5 # systemctl status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Thu 2018-01-04 10:08:36 GMT; 2s ago # virsh capabilities Displays capabilities of host and guest systems virt-manager connects to "localhost (QEMU)" I can create a VM and boot an iso This update of libvirt still looks OK to me
I also downgraded qemu on mga5-32. The libvirt update works fine there too.
I just thought to check something that hadn't occurred to me before, I went to add a new connection in virtual manager and selected user session and not system which is the default and where all my vms are, that connection worked with no error messages, no vms there of course but i'm going to try to make one. is it possible that my configs may now be non-working with the newer libvirt?
okay fixed it but i don't know why this worked: edit my /etc/libvirt/qemu.conf such that i commented out the 'user' and 'group' entries, restarted libvirtd and voila! there were my guests in virtual manager! i then removed the comments, putting back /etc/libvirt/qemu.conf to how it's been for a year or so, restarted libvirtd again, and now even though the system would seem to be identical to how it was before, there is however no error message and my guests show up in virtual manager. so am i really odd in using those two options in /etc/libvirt/qemu.conf?