Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 583950 (CVE-2014-3672) - <app-emulation/libvirt-1.3.4: DoS via excessive logging
Summary: <app-emulation/libvirt-1.3.4: DoS via excessive logging
Status: RESOLVED FIXED
Alias: CVE-2014-3672
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: B3 [noglsa]
Keywords:
Depends on: 587624
Blocks:
  Show dependency tree
 
Reported: 2016-05-24 10:39 UTC by Agostino Sarubbo
Modified: 2016-07-05 12:14 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2016-05-24 10:39:35 UTC
From ${URL} :

A while back, Mr Andrew Sorensen reported a Qemu logging issue wherein Libvirt 
OR Xen directed 'stderr' of Qemu to a log file on the host.

This can be easily exploited by a user inside guest to flood the log file with 
endless messages, resulting in a DoS situation on the host, affecting other 
services and guests alike.

'CVE-2014-3672' was assigned to it by Red Hat Inc.

Until recently there was no remedy in sight, but quoting Mr Daniel P Berrange 
of libvirt

   "Since libvirt version 1.3.3, libvirt has 'virtlogd' daemon running. The
    QEMU stdout/err are no longer connected directly to a file on disk, instead
    they go to a pipe connected to virtlogd. virtlogd only allows 128 kb of
    data to be written before rolling over the logs, and only keeps 3 backups,
    so there is no longer an uncontrolled denial of service.

    With QEMU 2.6, it is further possible to use virtlogd in association with
    QEMU serial ports that need to log to a file, for the same reason."

Upstream patch:
---------------
   -> https://libvirt.org/git/?p=libvirt.git;a=commit;h=0d968ad715475a1660779bcdd2c5b38ad63db4cf

Note: It's probably not feasible to back port this solution to older versions.
Comment 1 Matthias Maier gentoo-dev 2016-05-31 21:20:00 UTC
Given the very nature of this vulnerability I will proceed with the regular stabilization of version 1.3.4 in 2 weeks and cleanup all older versions afterwards.
Comment 2 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-06-13 10:15:27 UTC
Matthias, friendly reminder to call for stabilization if you are ready.
Comment 3 Matthias Maier gentoo-dev 2016-06-13 14:58:40 UTC
Well, if you insist ;-)

Arches please stabilize
  =app-emulation/libvirt-1.3.4
  =dev-python/libvirt-python-1.3.4

Target keywords: amd64 x86
Comment 4 Agostino Sarubbo gentoo-dev 2016-06-14 10:20:10 UTC
amd64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2016-06-27 08:50:35 UTC
x86 stable.

Maintainer(s), please cleanup.
Comment 6 Matthias Maier gentoo-dev 2016-06-30 16:19:29 UTC
commit 0767c3300884f46c34cd6b65af08ae6d19111b80
Author: Matthias Maier <tamiko@gentoo.org>
Date:   Thu Jun 30 11:12:55 2016 -0500

    dev-python/libvirt-python: drop old versions 1.2.21, 1.3.1
    
    Package-Manager: portage-2.2.28

commit 31eba666d070804f00c7285f4d2f9f7ea6b672c7
Author: Matthias Maier <tamiko@gentoo.org>
Date:   Thu Jun 30 11:11:44 2016 -0500

    app-emulation/libvirt: drop old versions 1.2.21, 1.3.1
    
    Package-Manager: portage-2.2.28
Comment 7 Matthias Maier gentoo-dev 2016-06-30 21:41:10 UTC
commit e7da1ecc9f9fd770ffc705a4224257c6a24dd267
Author: Matthias Maier <tamiko@gentoo.org>
Date:   Thu Jun 30 16:39:43 2016 -0500

    Revert "dev-python/libvirt-python: drop old versions 1.2.21, 1.3.1"
    
    This reverts commit 0767c3300884f46c34cd6b65af08ae6d19111b80.

commit 07b76b118c8ea9c922b5686d335b499fff5a7fb9
Author: Matthias Maier <tamiko@gentoo.org>
Date:   Thu Jun 30 16:39:09 2016 -0500

    Revert "app-emulation/libvirt: drop old versions 1.2.21, 1.3.1"
    
    This reverts commit 31eba666d070804f00c7285f4d2f9f7ea6b672c7.
Comment 8 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-07-05 12:14:58 UTC
GLSA Vote: No