Bugzilla – Bug 987527
VUL-1: CVE-2016-5008: libvirt: empty VNC password disables authentication
Last modified: 2019-11-08 15:42:40 UTC
Vivian Zhang and Christoph Anton Mitterer discovered that setting an empty VNC password does not work as documented in Libvirt, a virtualisation abstraction library. When the password on a VNC server is set to the empty string, authentication on the VNC server will be disabled, allowing any user to connect, despite the documentation declaring that setting an empty password for the VNC server prevents all client connections. With this update the behaviour is enforced by setting the password expiration to "now". similar: bug 663616 References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-5008 http://www.debian.org/security/2016/dsa-3613
https://bugzilla.redhat.com/show_bug.cgi?id=1180092 https://libvirt.org/git/?p=libvirt.git;a=commit;h=bb848feec0f3f10e92dd8e5231ae7aa89b5598f3
Was able to reproduce. Configure a VM with VNC Server display and set an empty password. The discrepancy is claimed between the libvirt documentation and what actually happens, as well as between the spice and VNC access methods. I am not sure if the user is supposed to expect anything when setting an empty password. Certainly in the virt-manager UI the user is clearly led to believe that access is granted, albeit with an empty password. Setting as VUL-1 to be fixed with the next available update.
All maintained products affected: openSUSE 13.2, Leap 42.1, Factory/Tumbleweed, SLE11 SP4, and SLE12 SP1. SLE12 SP2 and Leap 42.2 need patched as well.
(In reply to James Fehlig from comment #3) > All maintained products affected: openSUSE 13.2, Leap 42.1, > Factory/Tumbleweed, SLE11 SP4, and SLE12 SP1. > > SLE12 SP2 and Leap 42.2 need patched as well. Not quite right. Factory/Tumbleweed, SLE12 SP2 and Leap 42.2 have libvirt 2.0.0, which already contains the fix. I've added the fix to the SLE11 SP4, SLE12 GA (in case we ever do an LTSS update), and SLE12 SP1 libvirt packages and have them queued for a future maintenance update. For openSUSE, I've entered MR#406878 for 13.2 and MR#406879 for Leap 42.1. I think I'm done here, with exception of 11 SP4 and 12 SP1 maintenance requests. Would you prefer those now or hold off for future maintenance cycles?
This is an autogenerated message for OBS integration: This bug (987527) was mentioned in https://build.opensuse.org/request/show/406878 13.2 / libvirt https://build.opensuse.org/request/show/406879 42.1 / libvirt
(In reply to James Fehlig from comment #4) > I think I'm done here, with exception of 11 SP4 and 12 SP1 maintenance > requests. Would you prefer those now or hold off for future maintenance > cycles? This issue will be fixed with a future update, to be requested later.
(In reply to Andreas Stieger from comment #6) > This issue will be fixed with a future update, to be requested later. Thanks, I'll close the bug then.
bugbot adjusting priority
Re. #8: Heh, sorry. I should know better... I've submitted libvirt for SLE11 SP4 (sr#118005) and SLE12 SP1 (sr#118006) maintenance. Thanks.
openSUSE-SU-2016:1809-1: An update that solves one vulnerability and has two fixes is now available. Category: security (moderate) Bug References: 854343,968483,987527 CVE References: CVE-2016-5008 Sources used: openSUSE 13.2 (src): libvirt-1.2.9-31.1
openSUSE-SU-2016:1810-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 987527 CVE References: CVE-2016-5008 Sources used: openSUSE Leap 42.1 (src): libvirt-1.2.18.2-11.1
testing libvirt update I have found out that the issue with empty VNC password can be reproduced and its fixed within the libvirt on top of KVM host. However, using Xen host I am able to reach the system using virt-viewer even with empty vnc password used in guest configuration (after update of libvirt on top of XEN host). Is that expected behavior (issue fixed for KVM but not for XEN host)? => vnc config for xen guests <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' passwd=''> <listen type='address' address='0.0.0.0'/> </graphics> => however when I use a proper passwd instead of empty string, passwd is required using virt-viewer and xen guests. Thank you
(In reply to Branislav Havel from comment #15) > using Xen host I am able to reach the system using > virt-viewer even with empty vnc password used in guest configuration (after > update of libvirt on top of XEN host). Is that expected behavior (issue > fixed for KVM but not for XEN host)? WRT libvirt, yes, it is expected behavior. For KVM/QEMU, libvirt controls spawning qemu and subsequent configuration via the monitor. For Xen, xend/libxl handles all this dirty work. IMO, a similar fix needs to be made in xend/libxl. I've sent a mail to security@xenproject.org enquiring about this CVE.
I don't think anything can be done for the differences in behavior we see between libvirt+Xen and libvirt+KVM/QEMU. I received the following response from Ian Jackson on security@xenproject.org list "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted; and in that case, no password option is passed on the qemu command line." So from Xen's perspective, an empty vncpasswd means no auth. From a libvirt qemu driver perspective, an empty vncpassed means no vnc access. It is not possible to change the Xen behavior in libvirt since libvirt has no control over the qemu process spawned by libxl. And upstream Xen clearly doesn't want to change the behavior they have defined. I'd prefer disallowing an empty vncpasswd, but such a change would break backwards-compatibility https://www.redhat.com/archives/libvir-list/2016-August/msg00072.html I think we will have to live with this difference of opinion between the two camps.
SUSE-SU-2016:1944-1: An update that solves one vulnerability and has two fixes is now available. Category: security (moderate) Bug References: 952889,970906,987527 CVE References: CVE-2016-5008 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): libvirt-1.2.5-15.3 SUSE Linux Enterprise Server 11-SP4 (src): libvirt-1.2.5-15.3, perl-Sys-Virt-1.2.5-4.2 SUSE Linux Enterprise Debuginfo 11-SP4 (src): libvirt-1.2.5-15.3, perl-Sys-Virt-1.2.5-4.2
openSUSE-SU-2016:1975-1: An update that solves one vulnerability and has one errata is now available. Category: security (moderate) Bug References: 987527,989755 CVE References: CVE-2016-5008 Sources used: openSUSE Leap 42.1 (src): libvirt-1.2.18.4-14.2
SUSE-SU-2016:2053-1: An update that solves one vulnerability and has four fixes is now available. Category: security (moderate) Bug References: 854343,968483,975729,987527,989755 CVE References: CVE-2016-5008 Sources used: SUSE Linux Enterprise Workstation Extension 12-SP1 (src): libvirt-1.2.18.4-11.7 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): libvirt-1.2.18.4-11.7 SUSE Linux Enterprise Server 12-SP1 (src): libvirt-1.2.18.4-11.7 SUSE Linux Enterprise Desktop 12-SP1 (src): libvirt-1.2.18.4-11.7
seems done
SUSE-SU-2018:2141-1: An update that solves 5 vulnerabilities and has 7 fixes is now available. Category: security (important) Bug References: 1076500,1079869,1083625,1092885,854343,897352,954872,956298,964465,968483,980558,987527 CVE References: CVE-2016-5008,CVE-2017-5715,CVE-2018-1064,CVE-2018-3639,CVE-2018-5748 Sources used: SUSE Linux Enterprise Server 12-LTSS (src): libvirt-1.2.5-27.13.1
I've backported the fix to SLE11 SP3 libvirt package and queued it for a future maintenance submission. As for SLE10 SP3 and SLE11 SP1, they do not support setting VNC, SPICE, etc passwords through the qemu monitor. Hell, they don't even support SPICE.
(In reply to James Fehlig from comment #29) > I've backported the fix to SLE11 SP3 libvirt package and queued it for a > future maintenance submission. The future arrived early. I've submitted it.
released