Test dnsmasq available, fix for potential cache poisoning vulnerability

July 10th, 2008 by Chris Buechler

While the author of dnsmasq does not feel it is susceptible to the recent DNS vulnerability “panic”, he did release an updated RC version including query source port randomization. It appears dnsmasq is not vulnerable because it does not do any recursive queries – it relies entirely upon your ISP’s DNS servers or internal ones you have defined. Hence it appears that as long as your ISP isn’t vulnerable, you aren’t vulnerable. If you have instead defined internal DNS servers, they are the ones that will need to be patched.

The DNS server package in pfSense uses djbdns, which is the only major DNS server package that was not vulnerable.

We feel it’s safe to say this probably does not affect dnsmasq in pfSense – but we can’t say for sure until the details are released at Black Hat in August. This fix is still a good one to deploy because it makes other potential cache poisoning vectors much more difficult.

Please help us test this new version of dnsmasq. This is for 1.2-release systems only, those using 1.2.1 or 1.3 snapshots can update by installing a new full update from the snapshot server. We have been testing it and have not found any issues.

To install the updated dnsmasq on pfSense 1.2 full installs:

  1. Go to a command prompt (SSH or Diagnostics -> Command)
  2. Run the following commands one by one.

killall dnsmasq
mv /usr/local/sbin/dnsmasq /root/
fetch -o /usr/local/sbin http://cvs.pfsense.org/~sullrich/dnsmasq
chmod +x /usr/local/sbin/dnsmasq
/usr/local/sbin/dnsmasq

At that point you will be running the updated dnsmasq and everything should be working properly.

Thanks to dnsmasq author
Thanks much to Simon Kelley for making a dnsmasq update available so quickly, and promptly replying to our inquiry!

Updated release information
Once this fix has been more widely tested, we will release pfSense 1.2a with only this change. Based on the information we have available, this currently does not warrant a wrecklessly quick fix with the potential cost of stability. All things at this time point to this specific issue being applicable only to servers that issue recursive queries, and hence not dnsmasq.

13 Responses to “Test dnsmasq available, fix for potential cache poisoning vulnerability”

  1. Juve Says:

    I’ve tested it and no problems occurs. I have patched 30 pfsense (with the old dnsmasq backed up). If any problem occurs I’ll give feedback

  2. Martin Says:

    Works like a charm here on 2 systems…
    No problems occured…

  3. A.D. Says:

    Thanks for this udate. 2 machines are OK.

    How about 1.3? Does this fix can be applied to 1.3?
    (Should test it for myself, but I’d better ask)

  4. Jonathon Says:

    Not much of unix guy/admin, but on my home setup it seems to be working fine, even after rebooting the machine.

    Thanks!

  5. Chris Buechler Says:

    Thanks for the reports!

    A.D.: Read the post. “This is for 1.2-release systems only, those using 1.2.1 or 1.3 snapshots can update by installing a new full update from the snapshot server.”

  6. Adam Says:

    Commands do not work via SSH and Console on 1.2 embedded

    PFbox:~# killall dnsmasq
    PFbox:~# mv /usr/local/sbin/dnsmasq /root/
    mv: rename /usr/local/sbin/dnsmasq to /root/dnsmasq: Read-only file system

    Confirmed working via WebGUI Command 1.2 embedded

    Jul 11 15:16:33 dnsmasq[4339]: started, version 2.43rc3 cachesize 150
    Jul 11 15:16:33 dnsmasq[4339]: compile time options: IPv6 GNU-getopt BSD-bridge ISC-leasefile no-DBus no-I18N TFTP
    Jul 11 15:16:33 dnsmasq[4339]: reading /etc/resolv.conf
    Jul 11 15:16:33 dnsmasq[4339]: using nameserver x.x.x.x#53
    Jul 11 15:16:33 dnsmasq[4339]: using nameserver x.x.x.x#53
    Jul 11 15:16:33 dnsmasq[4339]: read /etc/hosts – 2 addresses

  7. Chris Buechler Says:

    For embedded, you first need to run:

    /etc/rc.conf_mount_rw

    and when done:

    /etc/rc.conf_mount_ro

  8. Ronpfs Says:

    Remember to use the ip and not the domain name for the WebGUI / Diagnostics -> Command, cause you gonna kill the DNS server during the procedure.

  9. Adam Says:

    For DNS Resloving in the shell i believe it uses /etc/resolv.conf and asks the DNS servers directly. I killed dnsmasq and was able to ping domain names from the shell all day long. I also did the update with the domain name and it worked fine.

    Using the ip can’t hurt :)

  10. Chris Buechler Says:

    Fetching the updated file isn’t relevant to whether or not dnsmasq is running, since the local system uses /etc/resolv.conf.

    I think ronpfs means don’t access the webGUI by hostname if your client is using that system for its DNS. That shouldn’t matter either as the DNS cache on your client system should be more than long enough to accommodate doing this, but it’s not bad advice.

  11. Chris Uthe Says:

    Working great on 1.2 stable here!

  12. Ronpfs Says:

    Chris said “don’t access the webGUI by hostname if your client is using that system for its DNS.”

    That is exactly what I meant ;o) Not a big thing cause once your client can’t resolve the hostname a few synaps fire and you switch to IP ;o)

    Working ok here too

  13. pfSense Digest » Blog Archive » DNS vulnerability details now publicly available Says:

    [...] own DNS server and haven’t patched yet – now would be the time to do so. The details of the previously mentioned vulnerability were inadvertently made publicly available earlier [...]

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