Bug 14192

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 => 4
Assignee: bugsquad => qa-bugs
Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Severity: 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.

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) => olchal
Whiteboard: 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_update
Whiteboard: 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-OK
CC: (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 => RESOLVED
Resolution: (none) => FIXED