dnsmasq in untangle

[1900]

untangle 5.3 appear to use dnsmasq 2.22.

Is this version susceptable to the DNS cache security issue.

Is this planed to be updated to 2.43 anytime soon?

Thanks


http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1447
http://www.kb.cert.org/vuls/id/800113

[goplaycheckers]

Well, according to the solution on this page, 2.22 is not vulnerable.

But just for fun, you could check to see if you're vulnerable anyway.

[Evil_Bert]

Well, according to the solution on this page, 2.22 is not vulnerable.

But just for fun, you could check to see if you're vulnerable anyway.

That's an old vulnerability, so the question remains.

I've been following this for the last couple of weeks. Many security researchers and bloggers are saying that DNS clients and local servers (as opposed to full, recursive DNS servers of the type your ISP runs) are also vulnerable, even if not performing recursion. I assume that this is true. So, what it boils down to, is:

Q1. Does Untangle, acting as a local DNS server with dnsmasq 2.22, use highly-randomised UDP source ports for upstream requests?
A1. No - dnsmasq version 2.43 or better is required.

Q2. Does Untangle, acting as a NAT router with no local DNS server, preserve UDP source port randomisation from downstream clients performing lookups to upstream DNS servers?
A2. I don't know!

Since I use Untangle as a transparent bridge, I don't know the answer to the second question. But, it does seem to be important, since there are reports that even desktop OS's with stub resolvers are vulnerable (although a Linux desktop with kernel 2.6.24 onward does randomise UDP source ports).

There is a simple test you can perform from a Linux terminal (don't ask me if there's a Windows equivalent ... ):

dig +short @192.168.1.1 porttest.dns-oarc.net txt

... where you can substitute the IP address of the DNS service you wish to test after the '@' symbol - for me, this has only worked for local services. You can use this test to tell whether your local WAN interface is sending DNS requests upstream from randomised UDP ports ... i.e., whether your local equipment is vulnerable or not.

Note that Dan Kaminsky's test script at his www.doxpara.com site will test your upstream DNS server.

Also note that if your network sits behind some other NAT device, and you have patched your local DNS servers, you are probably still vulnerable because although your patched servers or clients are now happily randomising UDP source ports for DNS lookups, your NAT device is busily de-randomising them a moment later.

It seems we have to wait until Dan Kaminsky's address at Black Hat 2008 (sometime August 2-7) to get the full details of the vulnerability.

[sky-knight]

I can answer question 2... the NAT engine rerandomizes the port from the client again... so it isn't preserving it at all it's changing it a second time.

[Evil_Bert]

That's good to know. How random is it? Any chance someone can post results of "dig +short .." for their setup (with Untangle doing NAT)?

[sky-knight]

dig +short @10.10.10.1 porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "68.2.16.28 is GREAT: 26 queries in 0.7 seconds from 26 ports with std dev 20528"


Sure there it is... but it isn't testing the resolver in UT it's testing the resolver of my ISP.

[Evil_Bert]

Thanks.

I've conversed with one other person who reports similar - that the "dig + short ..." command is testing their ISP even if a local server IP address is specified - but most report it is testing their local gear, including me. Perhaps it's affected by resolv.conf after all.

[Evil_Bert]

Dan Kaminsky has finally given his presentation at Black Hat 2008, and revealed the full details of the DNS cache-poisoning vulnerability.

Opinions were mostly of the kind, "it's worse than we thought":

The scope of the problem was neatly summed up by George Kurtz, senior vice president and general manager of McAfee's Risk and Compliance business unit who told ChannelWeb: "When you hear about cache poisoning, most people think of attackers spoofing Websites, but when you go down the trail [Kaminsky] laid out, it's about taking over IPSec VPNs, SSL certification, all automatic updates for the software, Skype."

Although many large companies and ISPs have now patched their servers (so we're told) there's still a lot of users who remain vulnerable. As expected, the NAT/PAT contribution to the problem has been confirmed and the US-CERT vulnerability note has been updated with the latest details (see post #1 for link).

I've been saying for ages now that the internet is not a safe place ...

"We need to stop assuming the network is as friendly as it is," said Kaminsky. "...Every network is a hostile network."

You can get a copy of Dan Kaminsky's presentation at:http://www.doxpara.com/DMK_BO2K8.ppt.

[goplaycheckers]

Thanks for your posts. Interesting stuff!

[Spiral]

So I guess the question remains just how vulnerable Untangle is, or any dnsmasq implementation that is still unpatched for that matter. Does anybody else have any helpful input on this…?

Meanwhile I guess disabling the DNS server and using DHCP to push OPENDNS nameservers and add entries in Hosts file for local hostname resolution is a workaround.