This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include this bug ID and the bug IDs of this bug's parent bugs filed against the "Security Response" product (the top-level CVE bugs). Please mention the CVE IDs being fixed in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=833033 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs]
dnsmasq-2.63-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dnsmasq-2.63-1.fc17
Package dnsmasq-2.63-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnsmasq-2.63-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12598/dnsmasq-2.63-1.fc17 then log in and leave karma (feedback).
dnsmasq-2.63-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
In F18, my system still seems to be answering DNS queries from the outside world, on its "internal" IP address.
(In reply to Paul Wouters' comment https://bugzilla.redhat.com/show_bug.cgi?id=833033#c64, which should have been posted to this BZ instead) > I was hit by this now too. Worse, my dnsmasq was a participant in a DDOS > attack being queried with fake source IPs doing ANY queries for isc.org, a > well known amplifying query. > > 0:24:33.991446 IP 95.211.225.167.25345 > 76.10.157.69.domain: 10809+ [1au] > ANY? isc.org. (36) > 00:24:33.992160 IP 76.10.157.69.domain > 95.211.225.167.25345: 10809 27/0/9 > SOA, RRSIG, NS ams.sns-pb.isc.org., NS sfba.sns-pb.isc.org., NS > ord.sns-pb.isc.org., NS ns.isc.afilias-nst.info., RRSIG, A 149.20.64.42, > RRSIG, MX mx.ams1.isc.org. 10, MX mx.pao1.isc.org. 10, RRSIG, TXT "v=spf1 a > mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 The libvirt patches to solve this problem were pushed into libvirt's v0.10.2-maint branch at the end of November 2012, prior to 0.10.2.2; F18 is now on libvirt-0.10.2.4 (which I see you are using), so the vulnerability discussed in this BZ should no longer be an issue. > This is using Fedora 18 with libvirt-0.10.2.4-1.fc18.x86_64 > I'm changing this but to urgent Let's first be sure that you are seeing the same behavior. Can you attach the xml config for the network that defines the network using 76.10.157.69, and also the dnsmasq commandline that is generated for that network (run "ps -AlF | grep 76\.10\.157\.69").
After debugging this with Laine, the conclusion was that this was the result of a name space collision on using "virbr0" I believe this goes back to the xen and/or older fedora days, when at some point my use of "br0" broke with the then current name space of the virtualisation technology used, and I moved to "virbr0" (because I needed to hand out public IP to VMs on the box, and my LAN has a dhcp/dns server so I had to bridge eth0). But now libvirt uses that name space. As such, it started to run dnsmasq on virbr0, which was my outside connectivity. Renaming the bridge to br0 and rebooting confirmed no more dnsmasq's listening on public IPs. More people might be caught with this. Perhaps libvirt could check for a conflict of using the virbrX namespace in /etc/sysconfig/ifcfg-virbr* files and warn or refuse to start?
(In reply to comment #6) > After debugging this with Laine, the conclusion was that this was the result > of a name space collision on using "virbr0" > > I believe this goes back to the xen and/or older fedora days, when at some > point my use of "br0" broke with the then current name space of the > virtualisation technology used, and I moved to "virbr0" (because I needed to > hand out public IP to VMs on the box, and my LAN has a dhcp/dns server so I > had to bridge eth0). > > But now libvirt uses that name space. As such, it started to run dnsmasq on > virbr0, which was my outside connectivity. Paul, IOW you are saying that in certain scenarios the CVE-2012-3411 issue would be still there? > > Renaming the bridge to br0 and rebooting confirmed no more dnsmasq's > listening on public IPs. > > More people might be caught with this. Perhaps libvirt could check for a > conflict of using the virbrX namespace in /etc/sysconfig/ifcfg-virbr* files > and warn or refuse to start?
Yes. cat > /etc/sysconfig/networking-scripts/ifcfg-virbr0 DEVICE=virbr0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes cat > /etc/sysconfig/networking-scripts/ifcfg-eth0 DEVICE="eth0" ONBOOT=yes TYPE=Ethernet BOOTPROTO=none BRIDGE=br0 reboot, and you have dnsmasq running on virbr0 with the public ip (assuming dhcp hands out public ips, which it does in my home network) the real issue is that apparently libvirt has taken the "virbrXX" name space and assumes any such device names are its to manage. Unfortunately, others have also used "virbrXX" to denotate their own custom bridges. Ideally, libvirt would only do this for virbrXX devices it has itself created for virtual networks it started itself, regardless of name. Additionally, it would be nice if any dnsmasq instance started would per default ACL only reply to RFC1918 queries Finally, most of my networks don't need virt-manager/libvirt do hand out anything (its just bridged/routed to my public interface/bridge, or completely off-line static virtual networks that need no IP/DNS/DHCP via dnsmasq at all) but it seems it always wants some address range if configured via virt-manager.
>> Paul, IOW you are saying that in certain scenarios the CVE-2012-3411 >> issue would be still there? > Yes. I disagree. The only reason that libvirt's dnsmasq instance was accessible from the outside is because the system had been misconfigured (and then further misconfigured in an attempt to make it work). As long as nobody attaches a physical NIC to a bridge created by libvirt (which is something that should never be done), this won't happen. > the real issue is that apparently libvirt has taken the "virbrXX" name space > and assumes any such device names are its to manage. Unfortunately, others > have also used "virbrXX" to denotate their own custom bridges. libvirt has been using virbrX for its bridge names for at least 5 years (since at least Fedora 11, and for all of RHEL6, and at least part (if not all) of RHEL5 (I've only been around since 2009, so don't have details before that). I think the real issue is that NetworkManager and libvirt aren't doing a good enough job of avoiding stepping on each others' toes. If libvirt is told to start a network defined to use a bridge device that's already in use, it will give this error: error: Failed to start network default error: Unable to create bridge virbr0: File exists In your case, apparently libvirtd started before NetworkManager, so it created its device with no error. But then NetworkManager was told by its config (in /etc/sysconfig/network-scripts/ifcfg-virbr0, saw that it already existed, and instead of logging an error message, just used the existing device instead.
if "should never be done" applies to fools like me, I'm afraid there will be enough fools in the world to repeat my mistakes. Note that although I don't have the original ifcfg-* files to confirm, it is highly likely that my eth0 and virbr0 were configured with NM_CONTROLLED="no" If these dnsmasq's installs are being both DHCP server and DNS proxy, it should not be too hard to instruct dnsmasq to only reply to its own DHCP'ed range for DNS queries.