Multiple Vendor DNS Cache Poisoning Vulnerability

If you haven’t yet heard, there is a new DNS cache poisoning vulnerability out today. It could allow an unauthorized party to provide fake DNS replies that would be accepted by your DNS server, though the likelihood of this occurring in the near future is slim at best.

SANS ISC has a good overview of the issue, and the following advice:
“If you run a caching DNS server, patch it soon. I wouldn’t say “today, while ignoring sane patch management”. But check with your vendor and follow their guidance. The world is not going to end today.”

dnsmasq, the DNS caching server in pfSense, appears to be vulnerable to this. m0n0wall, stock firmware in Linksys routers, dd-wrt, IPcop, Clarkconnect, among a long list of other projects also use it and are equally affected. (at the moment, “equally affected” means “not affected at all” but that may change in the coming weeks)

As soon as an updated dnsmasq is available, we will provide a pfSense update. It will be 1.2a release, with the only change from 1.2 release being the updated dnsmasq.

In the mean time, it’s not really anything to be concerned about. Patch what you can now. We’ll have a pfSense update out as quickly as possible, which largely relies on the dnsmasq developer making an update available. The details of the vulnerability will be disclosed at a conference on August 6, after which point exploitation may be reasonably accomplished. Unlike most vulnerabilities, it isn’t easy to determine the specific issue by looking at the source code changes or reverse engineering patches, which significantly reduces the chance someone will figure out the specific problem before it’s disclosed.

Share this Post:

5 Responses to “Multiple Vendor DNS Cache Poisoning Vulnerability”

  1. yosama Says:

    would be a great feature addon for 1.3 if you guys could implement a package system for handling security updates, like yum, aptitude, or maybe use pkg_add (which already is in freebsd)

    using a package manager we could easily update minor stuff without a full “image” install.

  2. Chris Buechler Says:

    Yeah our current updating methodology does not provide differential updates, once an update is available you will have to use an update file with the entire OS, all applications and all the PHP code even though only dnsmasq will have changed. Technically if everyone was on 1.2 release we wouldn’t have to release everything, just an update with only the dnsmasq fix. But since there are dozens of different versions in use, that isn’t feasible with our existing update system.

    I don’t think this will be on the road map for 1.3 because there are so many other great things we’re adding and we only have so much time. This wouldn’t have much of an impact on the user vs. the same amount of time spent on some other functionality that a lot of people can benefit from. Personally, wearing my end user hat, I don’t care if the update is 40 MB or 2 MB. I would much rather that significant amount of time to provide differential updates be spent on improving functionality. It may change at some point in the future but likely not for 1.3.

  3. Bill McGonigle Says:

    I’m not sure we really need a differential update mechanism, per se – I only care about easy updates. Currently, on some of my hardware I have a single flash card on an IDE adapter with pfSense on it, and no room in the box for a second. To do a minor pfSense update I have to backup the config file, pull the thing out of the rack, unscrew the bottom cover, pull the card out, flash the card, put the card back in, put the screws in, rack it, configure a LAN interface, and then restore the config file. This is a minor pain, but creates a good 15 minutes of downtime if I’m fast with the screwdriver. Yeah, I know, CARP a second one in, but still it would be lovely it it were easier.

    I recall 1.3 gets us back the online updating mechanism – if that can preserve a config file, whether there’s anything fancier is almost immaterial – I don’t store any data on the box other than what’s in my config.xml. Sure, on a server I need yum, because there’s a heck of a lot of data that can’t get wiped out for a small update and the OS is gigabytes big. But a 40MB download for a pfSense update I can do in a couple clicks? – no problem.

  4. Chris Buechler Says:

    Ah, yeah the 1.2.1 and 1.3 upgrade systems are one click. Embedded is another story, that should be changing in 1.3 so it’s a reliable one click as well.

    On the topic of this post – it doesn’t appear dnsmasq is vulnerable to this, but given the lack of details the author isn’t sure. There is a slightly improved version available that we will be making available as an update once we can properly test it.

  5. pfSense Digest » Blog Archive » Test dnsmasq available, fix for potential cache poisoning vulnerability Says:

    […] pfSense Digest News, reviews and more related to the pfSense firewall project « Multiple Vendor DNS Cache Poisoning Vulnerability […]

Please don’t post technical questions or off-topic comments. It is far more likely that your questions and concerns will be addressed effectively through one of our support channels.

Leave a Reply