Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

Massive, Coordinated Patch To the DNS Released

Posted by kdawson on Tue Jul 08, 2008 02:12 PM
from the pretty-much-everybody dept.
Security Networking The Internet
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
internet networking security dnssec upgrade
it security
story

Related Stories

Firehose:DNS Vulerabilities NetSec Podcast Special EP by tkrabec (84267)
[+] The Backstory of the Kaminsky Bug 122 comments
Ant recommends a Wired piece on the background story of the Kaminsky DNS bug and its (temporary) resolution, decreasing the odds of a successful breach from 1 in 2^16 to 1 in 2^32. We've discussed this uber-hole a number of times. Wired follows the story arc from before Kaminsky's discovery of the bug to his public presentation of it in Las Vegas.
[+] Government Begins Securing Root Zone File 198 comments
Death Metal notes a Wired piece on the US government beginning the process of securing the root zone file. This is in service of implementing DNSSEC, without which the DNS security hole found by Dan Kaminsky can't be definitively closed. On Thursday morning, a comment period will open on the various proposals on who should hold the keys and sign the root — ICANN, Verisign, or the US government's NTIA.
[+] 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."
[+] DNS Poisoning Hits One of China's Biggest ISPs 86 comments
Support Code writes "ZDNet's Zero Day blog is reporting that a DNS server of one of China's largest ISPs has been poisoned to redirect typos to a malicious site rigged with drive-by exploits. The DNS poisoning attacks are affecting customers of China Netcom (CNC) and are using a malicious iFrame to launch exploits for known vulnerabilities in RealNetworks' RealPlayer, Adobe Flash Player and Microsoft Snapshot Viewer. In this interview with CNet, Dan Kaminsky confirms that attacks are definitely going on in the field."
[+] Technology: BIND Still Susceptible To DNS Cache Poisoning 146 comments
An anonymous reader writes "John Markoff of the NYTimes writes about a Russian hacker, Evgeniy Polyakov, who has successfully poisoned the latest, patched BIND with randomized ports. Originally, the randomized ports were never supposed to completely solve the problem, but just make it harder to do. It was thought that with port randomization, it would take roughly a week to get a hit. Using his own exploit code, two desktop computers and a GigE link, Polyakov reduced the time to 10 hours."
[+] Patch DNS Servers Faster 145 comments
51mon writes "Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn't patched, perhaps it is time to switch." After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet's security blog has an analysis.
[+] 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.
[+] Technology: Paul Vixie Responds To DNS Hole Skeptics 147 comments
syncro writes "The recent massive, multi-vendor DNS patch advisory related to DNS cache poisoning vulnerability, discovered by Dan Kaminsky, has made headline news. However, the secretive preparation prior to the July 8th announcement and hype around a promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference has generated a fair amount of backlash and skepticism among hackers and the security research community. In a post on CircleID, Paul Vixie offers his usual straightforward response to these allegations. The conclusion: 'Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.'"
[+] Package Managers As Achilles Heel 263 comments
An anonymous reader writes "Researchers from the University of Arizona have released a study that takes a look at the security of ten popular package managers. They were able to show all ten were vulnerable to attacks from a mirror or man-in-the-middle that allow an attacker to (along with other things) crash the system or obtain root access. Furthermore, the researchers created a fictitious administrator and company name and were able to lease a server and get it listed as an official mirror for all the distributions they tried (Ubuntu, Debian, Fedora, CentOS, and OpenSUSE). This raised the question: What keeps you up at night, the thought of attacks on your package manager or previously discussed and patched vulnerability in DNS?" justin samuel (one of the Arizona researchers) also points out a synopsis on CERT's blog.
[+] Technology: Another DNS Flaw Found, Patched 21 comments
darthcamaro writes "Remember the big DNS flaw that Dan Kaminsky 'discovered' last year? Well, it looks like another flaw in DNS has just been patched. This time it's an item that affects DNSSEC, which was supposed to be the savior for the Kaminsky flaw. The good news, though, is that this time, the issue is relatively minor and DNS has already been patched. 'The flaw is specific to certain usages of DNSSEC,' Joao Damas, senior programming manager of the ISC told InternetNews. 'It is strongly advised that all BIND DNSSEC deployments update in case they are using the particular pattern affected (DSA keys in some cases) and to prevent coming across the problem in the future unexpectedly.'"
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Massive, Coordinated Patch To the DNS Released 25 Comments More | Login /

 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.

  • Oh cool! (Score:5, Funny)

    by RockMFR (1022315) on Tuesday July 08 2008, @02:18PM (#24104409)
    http://www.doxpara.com/ [doxpara.com]

    Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.

    Sweet!

    • Re:Oh cool! (Score:5, Funny)

      by brunascle (994197) * on Tuesday July 08 2008, @02:23PM (#24104489)

      http://www.doxpara.com/

      Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.

      In fact, we arent even www.doxpara.com, we just hacked your name server. That's how we know.

      • Re:Oh cool! (Score:5, Insightful)

        by GeffDE (712146) on Tuesday July 08 2008, @03:37PM (#24105581)
        Seriously, is an IP address too much to ask?

        Article should be modded +1 Ironic because the links necessitate the use of DNS...at the very least, the DNS checker should have been a straight IP.

        WTF?

  • not that big of a problem (Score:5, Informative)

    by simul (113898) * <slashdot@documentroot.com> on Tuesday July 08 2008, @02:20PM (#24104459) Homepage

    I used to run a DNS hosting company. Fortunately, this error only affects caching resolvers, since it is yet another example of cache poisoning. There have been (and continue to be) hundreds of cache poisoning exploits over the years. This one is fairly technical and would require significant expertise to execute in a timeframe (ie: before everyone patches up) to cause harm. I don't know about you,but if someone started flooding my servers with thousands of response regords in hopes of guessing a transaction ID, my iptables config would block them in a heartbeat.

    this is not the kind of security problem that should cause people's heart to skip a beat. your average malware worm is much worse.

    dan has written an article on a javascript attack that can compromise a home router [google.com].... that's probably far worse - in terms of real damage (ie: bot creation, personal data stolen)

    in sum... run yum update.... then don't worry about it.

  • Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.

  • Reverse Engineering? (Score:5, Informative)

    by ergo98 (9391) on Tuesday July 08 2008, @02:24PM (#24104525) Homepage Journal

    From the summary-

    The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible

    His DNS tester is submitting a DNS check that it knows will be relayed, and then monitoring if the upstream check (it is intentionally doing lookups against a DNS server it controls) consistently uses the same source port. If it does, hypothetically an attacker could send "response" packets in concert with the original request, poisoning the cache.

    I would guess that the patch makes the DNS server randomize the nonce when relaying DNS requests.

    I know nothing about this, but that's my super-l33t-hacker assumption from looking at it for 10 seconds.

  • Finally...! (Score:5, Funny)

    by JackassJedi (1263412) on Tuesday July 08 2008, @02:36PM (#24104687)
    I'm (sort of) a native German speaker, in which "DNA" is abbreviated "DNS" ("DesoxyribonukleinsÃure" with "sÃure" being "acid").
    Needless to say, my first impression of the headline was way more futuristic than what is there.

  • Nature of the attack (Score:5, Informative)

    by Animats (122034) on Tuesday July 08 2008, @02:41PM (#24104739) Homepage

    It's reasonably obvious from the CERT advisory how an attack would work. The CERT advisory tells us that the vulnerable systems are ones where the 16-bit DNS transaction ID and the 16-bit port number for a transaction are not randomly chosen. The CERT advisory also tells us that the attacker must be able to spoof IP addresses, that is, they must not be behind some ISP with egress filtering. CERT also tells us that it's a DNS poisoning attack.

    So it looks like a form of this attack documented in 2003 [net-security.org] at "Cache Poisoning using DNS Transaction ID Prediction". Back in 2003, it took a large number of packets to make this attack work, and even then it wasn't reliable. But there may be a more cost-effective attack strategy if you know how the DNS server assigns transaction numbers and ports.

    The fundamental problem comes from 1) the fact that source IP addresses can be forged, and 2) the DNS transaction ID, at 16 bits, is far too short to be considered a useful random key. Any key with security implications should be at least 64 bits and be generated by a crypto-grade random number generator.

  • Debian advisories.. glibc stub resolver effected! (Score:5, Informative)

    by molo (94384) on Tuesday July 08 2008, @02:47PM (#24104811) Journal

    Debian released 3 advisories:

    bind9:
    http://www.debian.org/security/2008/dsa-1603 [debian.org]

    bind8:
    http://www.debian.org/security/2008/dsa-1604 [debian.org]

    glibc:
    http://www.debian.org/security/2008/dsa-1605 [debian.org]

    Bind9 now contains a port randomization, which can require firewall rule changes.

    Bind8 is now considered deprecated and the advisory recommends upgrading to bind9. There is no patch for bind8.

    The glibc stub resolver is also vulnerable, and there is no patch yet. The recommended workaround is to install bind9 as a caching resolver and point /etc/resolv.conf at localhost.

    In short, this is a big mess.

    -molo

  • The real solution... (Score:5, Interesting)

    by Ethanol (176321) on Tuesday July 08 2008, @02:49PM (#24104843)

    ...is to sign the root and deploy DNSSEC.

    Unfortunately that's politically non-expedient. But now that this vulnerability is out there, maybe the political will can at last materialize.

    The second-best solution is to deploy DNSSEC using DNSSEC Lookaside Validation [rfc-archive.org] (which means you get trust anchors from some other known site, not from the root zone). And that's available now.

    The worst thing about DNSSEC is it's too damn complicated at present; there needs to be the equivalent of "one-click" zone signing. ISC (and others) are working on getting us closer to that.

    The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration. There's a difference between "harder" and "impossible" though.

  • djbdns apparently not affected (Score:5, Informative)

    by Mr.Ned (79679) on Tuesday July 08 2008, @03:02PM (#24105067)

    ... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html [cr.yp.to]

  • The Death of BIND (Score:5, Interesting)

    by Sevn (12012) on Tuesday July 08 2008, @03:43PM (#24105655) Homepage Journal

    I help admin one of the larger DNS systems (90,000+ zones) and our initial testing of the patched BIND showed it having half the performance of prior versions. That prompted us to very quickly replace all BIND caching servers with something else. We had already replaced authoritative services with something else because of BIND's lackluster performance. 3+ hours to load zones on reboot is quite frankly ridiculous. We really had no choice. Microsoft said they were going to open their mouths on a certain date, and we had a massive time crunch. We can't be the only company that simply had to ditch BIND. And I can't say I'm sorry to see it go. I'm sure mister Vixie is a great guy, but his domain name service is, and always has been complete garbage.

    • Re:Sinisterness (Score:5, Funny)

      by StreetStealth (980200) on Tuesday July 08 2008, @02:28PM (#24104581) Journal

      Still, it's not exactly like you clicked a banner with a lame attempt at a bouncing, fake window telling you your DNS software was in immediate need of a fix and that this combination patch and shopping buddy would fix it.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 SourceForge, Inc.