Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14
  1. #11
    Master Untangler
    Join Date
    May 2008
    Posts
    127

    Default

    This explains a little...

    From: Simon Kelley <simon@...>
    Subject: Update on DNS spoofing hole.
    Newsgroups: gmane.network.dns.dnsmasq.general
    Date: 2008-07-15 18:54:47 GMT (6 weeks, 2 days, 5 hours and 1 minute ago)

    Dnsmasq users:

    There has been some confusion about the exact nature of the
    newly-discovered DNS hole, and if dnsmasq is affected. I just talked to
    Dan Kaminsky and can confirm that dnsmasq is potentially vulnerable. All
    users should therefore upgrade. Ensure that the --query-port option
    (which will disable query-port randomisation) is _not_ used except on
    tightly-controlled networks.

    Also note that version 2.43, which was rushed out to fix this hole, has
    a crash bug in unrelated DHCP code. This is only triggered in rare
    circumstances. Distribution authors may like to wait for version 2.44,
    due next week, which fixes this problem.

    Cheers,

    Simon.

  2. #12
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,605

    Default Untangle risk

    Quote Originally Posted by sky-knight View Post
    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.
    Ok, so does that mean that any DNS server behind UT's NAT is effectively no worse than any other that has been recently patched?


    Jim

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

    Default

    Well the DNS resolver in UT can't be accessed unless it being hit from the internal network. So unless one of your machines gets hit, the resolver is fine. The vulnerability talks about cache poisoning, so in reality the machines that need patched are the internet cache servers provided by ISPs.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

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

    Default

    Quote Originally Posted by sky-knight View Post
    Well the DNS resolver in UT can't be accessed unless it being hit from the internal network. So unless one of your machines gets hit, the resolver is fine. The vulnerability talks about cache poisoning, so in reality the machines that need patched are the internet cache servers provided by ISPs.
    That's not really how it works. If, say, you browse to a specially-crafted webpage, your internal DNS server/resolver will be "hit" by the generated lookups from that web page (e.g. to a miriad of related elements that are owned by the attacker). There are other ways of generating lookups, too.

    Dan Kaminsky seems sure that any resolver can be "hit". I don't pretend to understand it as well as he does, but I'm guessing that recursive servers (of the type an ISP runs) are much easier to poison than a local DNS server or stub resolver due to traffic volume (and therefore the expected wait time until the attack is successful), but smaller resolvers are not immune.

    The basic problem (AFAICS) is predictability of DNS lookup requests and two simple facts: that the first answer received "wins" and that you can attach falsified "additional" information to that answer that gets cached - and every resolver caches to some degree.

    Hence the solution to randomise UDP ports used for DNS lookups so that the request is far less predictable. And hence the problem if a NAT device is de-randomising those UDP ports on the way out. The degree of randomness matters.

    It's definitely worth fixing at every level (I even convinced my router manufacturer to fix their firmware), but I suppose that local servers/stub resolvers will be less likely targets.
    There are many alternate universes, but only this one has beer.

Page 2 of 2 FirstFirst 12

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