A security issue in libvirt has been fixed upstream: http://libvirt.org/git/?p=libvirt.git;a=commit;h=3e745e8f775dfe6f64f18b5c2fe4791b35d3546b Mageia 3 and Mageia 4 are also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Debian has issued an advisory for this on September 27: https://www.debian.org/security/2014/dsa-3038
This issue, as well as CVE-2014-3657 are fixed upstream in 1.2.9: http://libvirt.org/news.html
Summary: libvirt new security issue CVE-2014-3633 => libvirt new security issue CVE-2014-3633 and CVE-2014-3657
Freeze push requested for Cauldron.
More info on CVE-2014-3657: https://bugzilla.redhat.com/show_bug.cgi?id=1145667
Ubuntu has issued an advisory for CVE-2014-3633 on September 30: http://www.ubuntu.com/usn/usn-2366-1/ Note the CVE-2014-5177 they also mention was fixed when we fixed CVE-2014-0179.
URL: (none) => http://lwn.net/Vulnerabilities/614390/
Upstream advisory for CVE-2014-3633: https://www.redhat.com/archives/libvir-list/2014-September/msg01164.html There are patches in every branch for that one. That is also the case for CVE-2014-3657, although they aren't labeled as such (just "domain_conf: fix domain deadlock"). RedHat has issued an advisory for CVE-2014-3657 today (October 1): https://rhn.redhat.com/errata/RHSA-2014-1352.html Updated package uploaded for Cauldron. Patched packages uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated libvirt packages fix security vulnerabilities: An out-of-bounds read flaw was found in the way libvirt's qemuDomainGetBlockIoTune() function looked up the disk index in a non-persistent (live) disk configuration while a persistent disk configuration was being indexed. A remote attacker able to establish a read-only connection to libvirtd could use this flaw to crash libvirtd or, potentially, leak memory from the libvirtd process (CVE-2014-3633). A denial of service flaw was found in the way libvirt's virConnectListAllDomains() function computed the number of used domains. A remote attacker able to establish a read-only connection to libvirtd could use this flaw to make any domain operations within libvirt unresponsive (CVE-2014-3657). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3633 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3657 https://www.redhat.com/archives/libvir-list/2014-September/msg01164.html https://rhn.redhat.com/errata/RHSA-2014-1352.html ======================== Updated packages in core/updates_testing: ======================== libvirt0-1.0.2-8.6.mga3.i586.rpm libvirt-devel-1.0.2-8.6.mga3.i586.rpm python-libvirt-1.0.2-8.6.mga3.i586.rpm libvirt-utils-1.0.2-8.6.mga3.i586.rpm libvirt0-1.2.1-1.2.mga4.i586.rpm libvirt-devel-1.2.1-1.2.mga4.i586.rpm libvirt-utils-1.2.1-1.2.mga4.i586.rpm from SRPMS: libvirt-1.0.2-8.6.mga3.src.rpm libvirt-1.2.1-1.2.mga4.src.rpm
Version: Cauldron => 4Assignee: bugsquad => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOOSeverity: normal => major
Procedure: https://bugs.mageia.org/show_bug.cgi?id=13387#c6 Start libvirtd service and then use virt-manager which is much like virtualbox to create and start a VM. It will ask for your root password and connect to the libvirtd service running on localhost then allow you to create/start/stop/view/alter any VM's running on it. virt-manager has an icon in the menu in tools => emulators. If you can start a VM, even just start an installation, it's enough to show libvirtd is working.
Whiteboard: MGA3TOO => MGA3TOO has_procedure
Testing complete mga3 64 Basic testing in vbox :) Used virt-manager to create and start a VM with boot.iso.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga3-64-ok
LWN reference for CVE-2014-3657: http://lwn.net/Vulnerabilities/614602/
Testing on MGA4-64 real H/W (Gnome) Installed packages - lib64virt-devel-1.2.1-1.2.mga4.x86_64 - lib64virt0-1.2.1-1.2.mga4.x86_64 - libvirt-utils-1.2.1-1.2.mga4.x86_64 and various dependencies. Installed virt-manager Version : 0.10.0-12.git1ffcc0cc.1.mga4 to make the test # systemctl enable libvirtd.service # systemctl start libvirtd.service Launched virt-manager in normal user mode Filled root-password Created 2 VM (puppylinux and ubuntu 14.10) create, start, halt, change settings..., whole installation of ubuntu in VM (all good with network connection) Just noticed that package python-libvirt is in version 1.2.1-1 (not 1.2.1-1.2) Everything OK
CC: (none) => olchalWhiteboard: MGA3TOO has_procedure mga3-64-ok => MGA3TOO has_procedure mga3-64-ok MGA4-64-OK
Testing on MGA4-32 real H/W (LXDE) Installed packages libvirt0 1.2.1-1.2.mga4 libvirt-devel 1.2.1-1.2.mga4 libvirt-utils 1.2.1-1.2.mga4 and dependencies Installed virt-manager 0.10.0-12.git1ffcc0cc.1.mga4 # systemctl -l status libvirtd.service libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since sam. 2014-10-04 00:49:34 CEST; 46s ago Docs: man:libvirtd(8) http://libvirt.org Main PID: 1901 (libvirtd) CGroup: /system.slice/libvirtd.service ââ1901 /usr/sbin/libvirtd ââ3530 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Launched virt-manager Created 1 VM (crunchbanglinux 20130506-i686) All went well as in mageia4-64
Whiteboard: MGA3TOO has_procedure mga3-64-ok MGA4-64-OK => MGA3TOO has_procedure mga3-64-ok MGA4-64-OK MGA4-32-OK
Testing complete mga3 32
Whiteboard: MGA3TOO has_procedure mga3-64-ok MGA4-64-OK MGA4-32-OK => MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-64-OK MGA4-32-OK
Validating. Advisory uploaded. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-64-OK MGA4-32-OK => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok MGA4-64-OK MGA4-32-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0401.html
Status: NEW => RESOLVEDResolution: (none) => FIXED