Red Hat Bugzilla – Bug 885727
Libvirt won't parse dnsmasq capabilities when debug logs are enabled
Last modified: 2013-02-21 02:28:23 EST
Description of problem: With enabled debug logs, libvirt fails to parse dnsmasq output which results in Bug 882265 - CVE-2012-3411 being reproducible again. Version-Release number of selected component (if applicable): libvirt-0.10.2-11.el6 How reproducible: 100% Steps to Reproduce: 1. enable debug logs (log_level=1) 2. restart libvirtd 3. virsh net-destroy default && virsh net-start default 4. ps axf | grep dnsmasq Actual results: 32677 ? S 0:00 /usr/sbin/dnsmasq --strict-order --local=// --domain-needed --pid-file=/var/run/libvirt/network/default.pid --conf-file= --bind-interfaces --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.253 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=252 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts Expected results: 7478 ? S 0:00 /usr/sbin/dnsmasq --strict-order --local=// --domain-needed --pid-file=/var/run/libvirt/network/default.pid --conf-file= --bind-dynamic --interface virbr0 --dhcp-range 192.168.122.2,192.168.122.253 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=252 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts (important diff is --bind-interfaces vs. --bind-dynamic) Additional info:
Fixed upstream: commit ff33f807739dc2950e4df8c1d4007ce9f8b290c0 Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Thu Dec 6 13:48:11 2012 +0100 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Thu Dec 6 13:48:11 2012 +0100 dnsmasq: Fix parsing of the version number If debugging is enabled, the debug messages are sent to stderr. Moreover, if a command has catching of stderr set, the messages gets mixed with stdout output (assuming both outputs are stored in the same variable). The resulting string then doesn't necessarily have to start with desired prefix then. This bug exposes itself when parsing dnsmasq output: 2012-12-06 11:18:11.445+0000: 18491: error : dnsmasqCapsSetFromBuffer:664 : internal error cannot parse /usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22' We can clearly see that the output of dnsmasq --version doesn't start with expected "Dnsmasq version " string but a libvirt debug output. v1.0.0-249-gff33f80
Hi.Michal Maybe I reproduce this bug without debug log enabled pls have a look https://bugzilla.redhat.com/show_bug.cgi?id=884957
(In reply to comment #4) > Hi.Michal > Maybe I reproduce this bug without debug log enabled > pls have a look https://bugzilla.redhat.com/show_bug.cgi?id=884957 No, I don't think they are the same. In the bug you are referring to, dnsmasq won't start as it can't bind to ::1. In this bug, dnsmasq doesn't die, but libvirt doesn't determine its version, so libvirt assumes it's older one, which doesn't support --bind-dynamic yet. Hence, dnsmasq is started with --bind-interfaces (which is the root cause of CVE). In your bug, --bind-dynamic is actually used so we're safe from the CVE POV.
Moving to POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-December/msg00168.html
(In reply to comment #5) > (In reply to comment #4) > > Hi.Michal > > Maybe I reproduce this bug without debug log enabled > > pls have a look https://bugzilla.redhat.com/show_bug.cgi?id=884957 > > No, I don't think they are the same. In the bug you are referring to, > dnsmasq won't start as it can't bind to ::1. In this bug, dnsmasq doesn't > die, but libvirt doesn't determine its version, so libvirt assumes it's > older one, which doesn't support --bind-dynamic yet. Hence, dnsmasq is > started with --bind-interfaces (which is the root cause of CVE). In your > bug, --bind-dynamic is actually used so we're safe from the CVE POV. Get it ,thank you for your analysis
Test is with libvirt-0.10.2-12.el6.x86_64, steps same as reporter said. Result: pkg:libvirt-0.10.2-12.el6.x86_64 4830 ? S 0:00 /usr/sbin/dnsmasq --strict-order --local=// --domain-needed --pid-file=/var/run/libvirt/network/default.pid --conf-file= --bind-dynamic --interface virbr0 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts So it's verified.
For now: libvirt-0.10.2-17.el6.x86_64 dnsmasq-2.48-13.el6.x86_64 ps -ef |grep dns nobody 8382 1 0 11:04 ? 00:00:00 /usr/sbin/dnsmasq --strict-order --local=// --domain-needed --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --bind-interfaces --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts there are "--except-interface lo --bind-interfaces" in the new dnsmasq process created by libvirtd
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html