Page 1 of 2 12 LastLast
Results 1 to 10 of 14
  1. #1
    Newbie
    Join Date
    May 2008
    Posts
    2

    Default dnsmasq in untangle

    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

  2. #2
    Untangler goplaycheckers's Avatar
    Join Date
    Jun 2008
    Location
    Tallahassee, FL
    Posts
    50

    Default

    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.
    Last edited by goplaycheckers; 07-24-2008 at 08:44 AM.

  3. #3
    Master Untangler Evil_Bert's Avatar
    Join Date
    Nov 2007
    Location
    Sydney, Australia
    Posts
    119

    Default

    Quote Originally Posted by goplaycheckers View Post
    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 ... ):

    Code:
    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.
    Last edited by Evil_Bert; 08-02-2008 at 05:16 AM. Reason: typo in code
    There are many alternate universes, but only this one has beer.

  4. #4
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,240

    Default

    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.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  5. #5
    Master Untangler Evil_Bert's Avatar
    Join Date
    Nov 2007
    Location
    Sydney, Australia
    Posts
    119

    Default

    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)?
    There are many alternate universes, but only this one has beer.

  6. #6
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,240

    Default

    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.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  7. #7
    Master Untangler Evil_Bert's Avatar
    Join Date
    Nov 2007
    Location
    Sydney, Australia
    Posts
    119

    Default

    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.
    There are many alternate universes, but only this one has beer.

  8. #8
    Master Untangler Evil_Bert's Avatar
    Join Date
    Nov 2007
    Location
    Sydney, Australia
    Posts
    119

    Default

    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":
    Quote Originally Posted by iTWire
    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 ...
    Quote Originally Posted by InformationWeek
    "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.
    There are many alternate universes, but only this one has beer.

  9. #9
    Untangler goplaycheckers's Avatar
    Join Date
    Jun 2008
    Location
    Tallahassee, FL
    Posts
    50

    Default

    Thanks for your posts. Interesting stuff!

  10. #10
    Master Untangler
    Join Date
    May 2008
    Posts
    127

    Default

    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.
    Last edited by Spiral; 08-28-2008 at 04:00 PM.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2