Bug 838528 - CVE-2012-3411 dnsmasq: When run under libvirt open DNS proxy (reachable also out of the virtual network set for the guest domain) is created [fedora-all]
CVE-2012-3411 dnsmasq: When run under libvirt open DNS proxy (reachable also ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnsmasq (Show other bugs)
16
All Linux
medium Severity medium
: ---
: ---
Assigned To: Douglas Schilling Landgraf
Fedora Extras Quality Assurance
: Security, SecurityTracking
Depends On:
Blocks: CVE-2012-3411
  Show dependency treegraph
 
Reported: 2012-07-09 07:39 EDT by Jan Lieskovsky
Modified: 2013-04-27 19:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-11 20:31:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2012-07-09 07:39:42 EDT
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]
Comment 1 Fedora Update System 2012-08-23 14:03:51 EDT
dnsmasq-2.63-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dnsmasq-2.63-1.fc17
Comment 2 Fedora Update System 2012-08-23 19:30:45 EDT
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).
Comment 3 Fedora Update System 2012-09-11 20:31:22 EDT
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.
Comment 4 David Woodhouse 2012-11-05 17:12:47 EST
In F18, my system still seems to be answering DNS queries from the outside world, on its "internal" IP address.
Comment 5 Laine Stump 2013-04-14 19:14:50 EDT
(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").
Comment 6 Paul Wouters 2013-04-15 11:59:46 EDT
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?
Comment 7 Jan Lieskovsky 2013-04-25 05:02:33 EDT
(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?
Comment 8 Paul Wouters 2013-04-25 17:56:41 EDT
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.
Comment 9 Laine Stump 2013-04-26 10:55:01 EDT
>> 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.
Comment 10 Paul Wouters 2013-04-27 19:54:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.