Reposting the relevant portions as a non-private comment: ... Yes, I think libvirt needs to be patched to use the new "--bind-dynamic" option. ... Aha, this works better: /sbin/dnsmasq --strict-order --bind-dynamic --local=// --domain-needed --pid-file=/var/run/libvirt/network/net3.pid --conf-file= --interface virbr1 --dhcp-range XXXXX --dhcp-leasefile=/var/lib/libvirt/dnsmasq/net3.leases --dhcp-lease-max=13 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net3.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/net3.addnhosts That is, I have to use '--interface virbr1' instead of '--except-interface lo --listen-address 90.155.50.33'. It still accepts requests received from lo, which confused me momentarily, but it *is* correctly dropping requests received from elsewhere. Although it would be better to reject them with UDP port unreachable errors, rather than reject. Dropping packets is always a bad thing.
(I just posted this same comment to the original bug) If libvirt changes its usage of dnsmasq to use --bind-dynamic , it *must* be done in a way that libvirt will continue to operate properly (including calling dnsmasq in an appropriate manner) even on systems that don't have a dnsmasq with --bind-dynamic. So, what must be done is to do a preliminary run of "dnsmasq --help", then parse the output to see if it contains --bind-dynamic, and *only then* change the behavior. Doing otherwise will adversely affect all the libvirt users who don't have a sufficiently modern dnsmasq (the vast majority of which will see no behavioral change from this commandline change anyway - see the next paragraph), and I don't see that as acceptable. Note that this situation only arises when a network is defined with <forward mode='route'>, and that is arguably the *least* common method of setting up a libvirt network by far (it's much more common to use <forward mode='nat'>) (Beyond that, in the general sense, I think this is actually how a listener on a publicly visible IP of a multihomed host for a port that has been opened for incoming connections "on all interfaces" is normally expected to operate (and remember that all the addresses in a libvirt network using <forward mode='route' are considered to be public). Granted, this is a slightly different situation, since this second interface is really there for the benefit of the guests, but truthfully once I read through all the comments and fully understood what was happening, my thought was "well of course it's responding." If it was the case that this dnsmasq instance was answering queries sent to the server's *external* IP address, or if queries from the external network to a truly private address (e.g. 192.168.122.1 of libvirt's "default" network which uses forward mode='nat') were responded to, that would be a more serious issue.) I'll happily cede that point though, and agree that we should make libvirt's DNS server instances only answer queries that originate from guests on that network's bridge. Collapse All Comments Expand All Comments Add Comment
If you're going to make it optional with a fallback for older versions of dnsmasq, then you should probably check for a non-RFC1918 IP address and refuse to run dnsmasq in that scenario. Better to fail and instruct the user to upgrade, than to be vulnerable.
I agree with David's point to refuse use of non-RFC1918 address ranges in the fallback case.
Note also that you'll have a similar issue if you're using dnsmasq to serve DNS over IPv6 to guests.
For IPv6 see RFC4193. The equivalent for the IPv4 RFC1918 addresses is FC00::/7 ... or really (as I see it) FD00::/8 for local IPv6 stuff. I am sure that someone has a valid reason to run real addresses on virtual network interfaces, these should be configured with extreme care. I can see a valid configuration with real addresses when testing ... but only if these addresses are used on virtual network interfaces with NO gateway addresses defined so that nothing can get to them from the virtualization host. Of course, I have always been a bit paranoid ;)
This is (In reply to comment #6) > I am sure that someone has a valid reason to run real addresses on virtual > network interfaces, these should be configured with extreme care. This is nonsense. There are just as many reasons to run with real addresses on virtual machines, as there are to run with real addresses on real machines. Any time you want *proper* connectivity, with the Internet Protocol(s) working end-to-end as designed, and you want the protocols that run on top (like SIP, FTP, etc.) to also work as designed without either breaking completely (as is often the case with SIP and all incoming connections including just being able to SSH into the virtual machine from the outside), or being subject to horrid unreliable ALG hacks to fudge around the problem (like FTP, IPSec, many others), you want to use real addresses.
(In reply to comment #7) > This is nonsense This type of comment is not helpful in reaching an optimal technical solution. I appreciate your thoughts on the technical merits of the proposals, but please try to keep your comments constructive.
> (In reply to comment #7) > This type of comment is not helpful in reaching an optimal technical > solution. I'm not sure I agree. A comment such as comment 6, effectively claiming that real addresses shouldn't normally be used on virtual interfaces and suggesting that those who *do* should just have to be wary of security bugs like this one, is completely out of place in this bug. It *is* nonsense, and it definitely needs to be treated as such. Saying that is not a personal attack, and I'm not saying the person who said it is a bad person or smells or has fleas or anything like that. I am not promoting an attitude of violence. This is not a kindergarten; it is a technical discussion. A point of view was presented which has no technical merit in this context — and I was pointing out, correctly, that it should be discounted. And why. The view presented in comment 6 should *not* be taken into consideration when attempting to reach a technical solution. It's *not* good enough simply to say 'caveat emptor'. If you'd like to rephrase that in language more suitable for the kindergarten where we need to be sure we don't make someone cry, then please go ahead and do that in your own head while *reading* it. I shall continue to assume an adult readership when using bugzilla.
Please, if you wish to continue the kindergarten-related metadiscussion, let's do it somewhere other than the context of this bug. For now let's focus on your response to comment 6. This bug is specifically about the vulnerable behaviour of libvirt *WHEN CONFIGURED WITH REAL ADDRESSES* with full connectivity. Any discussion of RFC1918 or site-local or ULA addressing is entirely off-topic. That *isn't* the configuration being discussed. Saying "don't use real addresses" is about as helpful in this bug as saying "don't use libvirt" would be. It's not clear what actual technical recommendation, if any, was being implied by comment 6. Was it being suggested that libvirt should *disallow* the use of real addresses completely, thus rendering it useless for any purpose where full connectivity is required? Was it being suggested that users who configure it thus should *anticipate* that it would have CVE-worthy vulnerabilities, and that we should not bother to fix the problem? And if so, does that same attitude apply to *any* CVE-worthy security bug in Fedora? Just say "oh, don't connect it to the Internet properly and it'll be fine", and don't bother to fix it? Or did I miss something that rendered comment 6 actually *useful* and relevant?
I am suggesting is that you refrain from referring to other people's comments as nonsense, particularly when those people are submitting patches and you are not. Whether you choose to accept that feedback is up to you, but you should consider whether your communications style contributes to or detracts from your ability to get what you want.
Can we stick to the technical discussion, please? I don't mind you doing the kindergarten thing and asking me not to refer to nonsense as 'nonsense' just in case I make someone cry (although I did ask for that to be elsewhere than in this bug). But the *important* thing — regardless of whether the words used were suitable for a child's environment — is that in the technical sense we understand that it *was* nonsense, and completely irrelevant and unhelpful in the context of this bug. I wouldn't want such wrong-headed thinking to derail a fix for a security bug when we already appear to have it fairly much wrapped up; it's just a case of *shipping* the fix. (I think you missed the fact that I *did* supply a patch to dnsmasq to fix this, btw. Although the maintainer chose to implement it a different way in the end, and didn't use my patch.)
I've posted a series of 3 patches resolving the libvirt part of the bug to libvir-list. After it is pushed, I will backport to the various distros: https://www.redhat.com/archives/libvir-list/2012-November/msg00942.html Please respond to the patch emails with specific comments/suggestions. Gene - thanks for pointing out the RFC for IPv6 local addresses. I wouldn't have thought to add that otherwise. David - thanks for reporting the problem, testing the dnsmasq fix, and providing the exact dnsmasq commandline that fixes the problem; that helped remove the guess work in getting the change correct. Also to Gene - you may notice that these patches end up replacing "--listen-address" with "--interface", so your patch for that will no longer be necessary :-)
In your patch 2/3, you don't include the fec0::/10 "site local" range. Admittedly, site-local is deprecated but it's still actually really useful (for site-local networks which aren't connected to the outside world, and RFC3484 still gets everything *right*). Since it's unlikely to be re-used any time soon for anything *other* than site-local addressing, perhaps it's worth including that range in your list of 'private' addresses?
I've pushed the necessary libvirt patches upstream and into the v0.10.2-maint branch, so they will be in the next libvirt build for F18. I still need to backport to v0.9.11-maint for F17. David - I did add FEC0::/10 as you suggested. Thanks for pointing it out.
Now that this BZ (which was originally opened against libvirt in F17) has been taken over for package "vulnerability", and is set for all Fedora releases rather than just F17, what Bug should we use to specifically track putting the libvirt fix into F17? Similar question for libvirt fix in F18? I've pushed the changes to their respective -maint branches (v0.9.11-maint and v0.10.2-maint, respectively) in upstream libvirt, and Fedora builds of libvirt are now always made from the upstream -maint branches, but there is now no bug that we can specify in a fedpkg update so that it will be automatically set to ON_QA when the package is pushed to updates-testing, and CLOSED when it is promoted to updates.
Created libvirt tracking bugs for this issue Affects: fedora-all [bug 882309]
The impact of this is "moderate" which is less than "important" and thus this bug does not qualify as a release blocking bug for F18 final. The release criterion in question [1] is: The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation) -1 blocker, +1 NTH
ditto tflink, -1 blocker, +1 nth.
Based on final release criterion (as mentioned above), -1 blocker, +1 nth
That makes for -3 blocker, moving to rejected
Sorry for the noise, forgot to move it to accepted NTH - a tested fix would be considered past freeze for F18 final.
libvirt-0.9.11.8-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:0276 https://rhn.redhat.com/errata/RHSA-2013-0276.html