Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

Kaminsky Bug Options Include "Do Nothing," Says IETF

Posted by timothy on Thursday November 20, @04:46PM
from the doing-stuff-is-overrated dept.
netbuzz writes "Meeting in Minneapolis this week, the Internet engineering community is debating whether to aggressively fashion and apply fixes for the so-called Kaminsky bug in the DNS discovered this summer, or to simply let its threat stand as motivation for all to move with greater speed toward DNSSEC, which is considered the best long-term security solution. Problem with the latter approach is that DNSSEC has been in the works for a decade already, no one is confident it will be universally embraced, and the Kaminsky flaw is causing real problems today.
internet it security bug dns
tech security
story

Related Stories

[+] Developers: Dan Kaminsky Suggests Having Fun with DNS 212 comments
boogahsmalls writes "A few weekends ago Dan Kaminsky of scanrand fame presented some pretty cool ideas involving DNS that made plenty of heads spin at the LayerOne Technology Conference. Some of his concepts included Voice over DNS and storing Knoppix in a DNS cache. He's also apparently got a couple new tools in the pipe including a scanrand based DNS scanner and a visualization suite. Could another version of Paketto Keiretsu be in the works?" (OpenOffice.org does a great job of opening the PowerPoint slideshow.)
[+] IT: Kaminsky's DNS Attack Disclosed, Then Pulled 281 comments
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak." Reader Time out contributes a link to coverage on ZDNet as well.
[+] IT: Apple Patches Kaminsky DNS Vulnerability 89 comments
Alexander Burke writes "Apple has just released Security Update 2008-005, which patches BIND against the Kaminsky DNS poisoning issue. 'This update addresses the issue by implementing source port randomization to improve resilience against cache poisoning attacks. For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1.' It also closes the script-based local privilege escalation vulnerabilities, the most common examples of which were ARDAgent and SecurityAgent, and addresses other less-publicized security issues as well." A few days back we noted Apple's tardiness in fixing their corner of this Net-wide issue.
[+] IT: Kaminsky DNS Bug Claimed Fixed By 1-Character Patch 120 comments
An anonymous reader writes "According to a thread on the bind-users mailing list, there is nothing inherent in the DNS protocol that would cause the massive vulnerability discussed at length here and elsewhere. As it turns out, it appears to be a simple off-by-one error in BIND, which favors new NS records over cached ones (even if the cached TTL is not yet expired). The patch changes this in favor of still-valid cached records, removing the attacker's ability to successfully poison the cache outside the small window of opportunity afforded by an expiring TTL, which is the way things used to be before the Kaminsky debacle. Source port randomization is nice, but removing the root cause of the attack's effectiveness is better."
Update: 08/29 20:11 GMT by KD : Dan Kaminsky sent this note: "What Gabriel suggests is interesting and was considered, but a) doesn't work and b) creates fatal reliability issues. I've responded in a post here."
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • DNS (Score:5, Funny)

    by Anonymous Coward on Thursday November 20, @04:51PM (#25838233)

    TMBG37 GOES TO THE MARKET
            -or-
    DNS for fucking idiots.
    (NONE LIKE IT HOT!)
     
    1. TMBG37 tries to go to www.dildomall.com with his browsar.
            a. His local machine checks if he's been there recently
              and if it remembers the IP address.
            b. Let's assume (big assumption people), that TMBG37
              hasn't been buying any rubbery cocks of late (ha!),
              his computar connects to its local nameserver.
                    --> HELO MISTAR NAMESERVAR
                    <-- Oh fuck it's you :(
                    --> WHERE DO I BUY DILDOES?
                    <-- Shit kid I don't even want involved with that.
                    --> GIVE ME ADDRESS FOR www.dildomall.com!!!!!
                    <-- Fuck you. But fine, its nameserver is
                        ns1.bunghole.org, which is 69.69.69.69.
                    --> THANK YOU SIR
            c. His computer goes on to pester ns1.bunghole.org, via
              its IP address, which it got from the local nameserver.
                    --> OMG R U ns1.bunghole.org?
                    <-- Oh christ, I've heard about you :(
                    --> OMG PLZ WHAT IS www.dildomall.com !!!!?
                    <-- Leave me alone.
                    --> PLXX?????
                    <-- It's 37.37.37.37
                    --> OMG HHLUAHGLAUHGALUHGUH *SUCKING DICK*
    2. TMBG37 goes on to happily penetrate his anus with a dildo
      bought from www.dildomall.com, with the IP address 37.37.37.37.
      There are HTTP/1.1 issues involved here if it is using virtual
      hosting, but that's NEITHER HERE NOR THERE.

  • and I am reading the wrong site. The aliens can return the real slashdot now. Surely IETF would never choose to "Do Nothing" :-)

  • by Vellmont (569020) on Thursday November 20, @05:01PM (#25838385)

    I'm trying to figure out exactly what they're deciding. Yes, I understand it's a discussion about "upgrade to DNSSEC" vs. "implement the hacks". But these guys don't control the internet, and my understanding is they only make "recommendations", which nobody is obliged to follow.

    So exactly what exactly are these guys debating about "doing"? Is it really just "recommend DNSSEC" or "recommend the hack"?

    • by JCSoRocks (1142053) on Thursday November 20, @05:09PM (#25838481)
      On top of that, recommending DNSSEC is starting to sound like recommending that everyone start playing Duke Nukem Forever.

      No one likes patching sinking ships but it's better than nothing. Doing nothing and waiting for DNSSEC are nearly the same thing.
      • Re: (Score:3, Insightful)

        sound like recommending that everyone start playing Duke Nukem Forever.

        Yes, with the limitation that only one can have the keyboard at a time.

        Considering that both Europe and China are launching their own satellite navigation networks, largely as a distrust issue, the idea that a single signed DNS root will be politically digestible over anything but a very short term shows a certain... detachment... from the actual politics of the world.

        I suspect that even if DNSSEC gets deployed to any large extent it'll

        • Re: (Score:3, Informative)

          The big problem is that most of the TLDs don't support DNSSEC (not sure if the root servers do, but I think they started a little while ago). This means that, even if you want to use DNSSEC, you can't, because the chain from the root to you is insecure and there is no chain of trust to you, so you gain nothing.
          • Re: (Score:3, Insightful)

            The big problem is that most of the TLDs don't support DNSSEC (not sure if the root servers do, but I think they started a little while ago).

            Well, they don't support some other as-yet-nonexistent alternate security fix for the Kaminsky Bug, either.

        • by Zero__Kelvin (151819) on Thursday November 20, @07:30PM (#25840203) Homepage
          From the Wiki article you link to:

          It is widely believed that deploying DNSSEC is critically important for securing the Internet as a whole, but deployment has been hampered by the difficulty of:

          1. Devising a backward-compatible standard that can scale to the size of the Internet
          2. Preventing "zone enumeration" (see below) where desired
          3. Deploying DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
          4. Disagreement among key players over who should own the .com (etc) root keys
          5. Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

          Some of these problems are in the process of being resolved, and deployments in various domains have begun to take place.

          I guess we have different definitions of "exists", unless you mean it exists as a list of as yet unsolved problems.

      • Re: (Score:3, Informative)

        Those patches are no fix, they only make the attack a little bit harder, and were easy to do without changing the current protocol or authoritative server software.

        Most of the proposed interim solutions do require a change in the protocol and/or authoritative server software, and those will need to be supported until the end of time (or when DNS goes away, which is probably not before a decade after that), and make debugging of misconfigurations that much harder, especially when several of these additions w

  • Old news? (Score:4, Informative)

    by Bearhouse (1034238) on Thursday November 20, @05:25PM (#25838719)

    As often, Ars Technica has had this for a while.

    http://arstechnica.com/news.ars/post/20080726-new-dns-exploit-now-in-the-wild-and-having-a-blast.html [arstechnica.com]

    I quote:

    "This would be less of an issue if the widely released patch from two weeks ago had been fully deployed"

    And:

    Moving to the more DNSSEC system would have solved this problem, and that idea was apparently floated, but it was dismissed on account of the tremendous overhead required by this protocol. The patch that currently exists is not a foolproof solution, but it minimizes the chances that the attack will succeed. "The exploit is now tens of thousands of times harder, but still possible," Kaminsky stated during his Black Hat webcast. "one in several hundred million to one in a couple billion."

    Yawn.

  • by Opportunist (166417) on Thursday November 20, @05:35PM (#25838885)

    Now, when, and I mean EVER, has a security hole meant that people switch to a new platform? Or when has a severe security hole EVER caused people to even consider moving?

    Windows has its leaks. But people keep using it. Why? Because they don't care, don't know or because "hey, what are the odds that it happens to me?". SMTP and POP have flaws, spam is running rampart because of it, and we switch to securer ways of mailing that can verify the sender... not! IPv4 has security problems and we're not even seriously considering switching to something more secure.

    People will NOT switch to something else just because of a security problem. Because the people who could enforce it simply don't care. ISPs? ISPs don't even care about trojans running rampart in their network. Most don't even bother trying to block Sasser from spreading. The governments? Spare me that, currently I'd rather expect them to use the flaw themselves for better surveillance of their subjects.

    Fix that damn bug! Nobody will move to a better platform just because of a "mere" security problem.

      • by Opportunist (166417) on Thursday November 20, @08:29PM (#25840735)

        No, DNSSEC would fix the bug. IF, and only IF, everyone used it. Actually the fact that DNSSEC accepts insecure DNS requests makes this approach flawed.

        It's not a technical problem. It's an economic one.

        Switching to DNSSEC means additional costs for ISPs. Additional time for server admins, additional hassle to get the verifications, signatures and certs. In one word, expense. Expense without revenue.

        Now, old school, insecure DNS works. The customer doesn't see a difference (most of all, he doesn't understand why DNSSEC would be a good idea, if he heard about it at all). Security has never been a selling point for ISPs. Price is. The customer won't request secure DNS and for almost every potential customer of an ISP the question whether a provider uses secure or insecure DNS is not going to influence his decision which one to take. If he has a choice at all, that is.

        I do agree that switching to DNSSEC would be a damn good idea. But you, me, some others on /. and a handful more understand the implications. That's not even a percent of a potential customer base for an ISP. So it doesn't matter.

        As long as there is no meaningful pressure on ISPs to adopt DNSSEC, they won't do it. And by meaningful, I mean someone or something requiring you to come from a provider address using DNSSEC to do business with you (banks come to mind). But since they again don't want to lose customers (due to requiring it while some other bank/business doesn't), they won't press for it either.

        If you want to force people to use DNSSEC, you have an ally in me. But you will not convince a sizable portion of the users, or even ISPs, just by keeping the alternative insecure. They won't care.

  • by leto (8058) on Thursday November 20, @06:02PM (#25839207) Homepage

    Stupid sensationalism.

    You can right now use draft-vixie-dnsex-dns0x20 [ietf.org] to protect against the kaminsky bug. This option is already available in the unbound [unbound.net] nameserver.

    Talking about totally talking out of context. Fools!

    If IETF does something to mitigate, the unbelievers scream "see we dont need dnssec"

    If IETF does not do something, the unbelievers scream "you're blackmailing us into dnssec"

    Stop whining and put your foot where your mouth is.

  • Misreported (Score:5, Informative)

    by Spazmania (174582) on Thursday November 20, @06:17PM (#25839419) Homepage

    I was in the meeting. As I recall, one gentleman, I'll repeat that, one gentleman from the audience of a few hundred got up and expressed the opinion that we should do nothing so as to spur DNSSEC deployment.

    There was rather more consensus for the view that we should avoid making quick hacks that might obstruct DNSSEC deployment since DNSSEC is currently the only approach on the table that we're reasonably sure ends the problem.

    • Is DJB's DNSCurve [dnscurve.org] a viable solution?

          • by jonaskoelker (922170) <jonaskoelker@@@gnu...org> on Friday November 21, @02:46AM (#25842811) Homepage

            Even an amateur cryptographer would tell you that the more you know about the message, the easier it is to break it.

            And a professional cryptographer would tell you to use a signature scheme that is provably secure (under standard cryptographic assumptions) against known plaintext signature forgery, and use a key big enough to satisfy you. Heck, you do all the crypto off-line, so you can pick a big one.

            Confidentiality protections reduce the amount of knowledge, and thus protect against attacks that are yet unknown.

            Prove the security of your signature scheme in the Universal Composability model and it's secure against all attacks, known and unknown.

            I don't think you know what you're talking about.

            Oh the iro... No, actually, you _do_ know what you're talking about: amateur cryptography.

            DNSCurve protects against denial of service attacks [link]

            So to back up your claim, you post a link to someone making the same claim. Now I'm convinced...

            It requires far less compute-power than DNSSEC.

            Yes, but it requires it on-line. It also requires caching keys for your clients unless you want to double your in- and outbound packet load.

            Read the page about DNSCurve. It says "DNSCurve and DNSSEC have complementary security goals. If both were widely deployed then each one would provide some security that the other does not provide."

            They're, taken at the word, not meant to replace each other.

    • by Al Dimond (792444) on Thursday November 20, @08:24PM (#25840693) Journal

      I don't know much about this sort of thing, but I bet it's relatively cheap to book in cold-weather cities in the winter.

      As a side benefit, it annoys Californians. Win all around.

    • Re:Minneapolis? (Score:4, Interesting)

      by Spazmania (174582) on Thursday November 20, @10:22PM (#25841481) Homepage

      Minneapolis has a "Skyway." [downtownmpls.com] Basically, many of he buildings downtown are connected via heated walkways between the second floors. These second floors form literally miles and miles of indoor pedestrian mall. The Hilton where the conference is held is connected to it.

      So basically you can go everywhere without having to ever go outdoors. And we have a gig-e Internet link for the duration of the conference. Its computer geek heaven.

    • Re:Minneapolis? (Score:4, Interesting)

      by mellon (7048) on Thursday November 20, @11:25PM (#25841883) Homepage

      Eh, the whole downtown is covered in habitrails, so you can walk from building to building in short sleeves, because you don't ever have to go outside. It's kind of like living on a really big space station, only with gravity.

      It was kind of cold in my hotel room, though.