Slashdot Mirror
Massive, Coordinated Patch To the DNS Released
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."
http://www.doxpara.com/
Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.
Sweet!
If you don't understand that, you don't need to care.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Here everyone, install this patch to your Unix/Linux DNS servers that was conceived of on the Microsoft campus.
While if true, one should be expedient to fix it, one should also be careful to verify that this is true.
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.... 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.
I don't see djbdns listed... except in the references and credits.
Do you even lift?
These aren't the 'roids you're looking for.
So, uhh, why the secrecy in planning the fixes?
Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.
My blog
FTA Update: Dan just released a "DNS Checker" on his site Doxpara.com to see if you are vulnerable to the issue.
in other news
Sooooooo, Im supposed to run a random file on my network to check an unknown DNS issue...this just reminds me all too much of those "download our program to fix all your antispyware issues" alerts.
And finally the obligatory profit usage:
1. Find a vulerability
2. Dont tell anyone what said vulnerability is.
3. Release malware in the form of a "Patch" to "Fix" the issue exploiting thousands of servers.
4. ???
5. PROFIT!
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
"An attacker with the ability to conduct a successful cache poisoning attack can cause a nameserver's clients to contact the incorrect, and possibly malicious, hosts for particular services. Consequently, web traffic, email, and other important network data can be redirected to systems under the attacker's control." Too bad the fix doesn't 'Cure' the problem. It only makes it more difficult. "ISC is providing patches for BIND 9.3, 9.4 and 9.5" - Thank the Internet gods.
This is utterly serious! And only a matter of time before attackers compromise DNS on servers and/or clients.
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.
And wow! Great news! There's a very critical flaw over the entire Internet name-to-IP infrastructure. But don't bother, it will take time before the bad guys find what we fixed...
From the summary-
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.
Error establishing a database connection
Towards the Singularity.
We only tolerate half-truths at Slashdot. Unless, of course, the truth coincides with what we believe. Then we're quite insistent on the whole truth thing.
Reading the article is, thus, a large gamble. I applaud suso for choosing wisely and avoiding the possibility of cognitive dissonance.
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.
Power corrupts the few, while weakness corrupts the many.
Here is the CERT advisory in a readable format.
http://www.kb.cert.org/vuls/id/800113
BTW, did they hold this for a Microsoft patch Tuesday?
-molo
Using your sig line to advertise for friends is lame.
Serious only if you're using BIND and a non-SOA DNS server. See http://secure64.com/products.shtml for good reasons to ditch BIND if you have some spare $$.
Remember: no cache, no fooling around with cache for giggles.
---- Teach Peace. It's Cheaper Than War.
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 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.
Good going Dan, this should add spice to the proceedings this year.
I like music
http://www.linuxcompatible.org/story115154.html
Oh joy!
Debian released 3 advisories:
bind9:
http://www.debian.org/security/2008/dsa-1603
bind8:
http://www.debian.org/security/2008/dsa-1604
glibc:
http://www.debian.org/security/2008/dsa-1605
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
Using your sig line to advertise for friends is lame.
Attention all DJB software fans, here's another chance to champion the superiority of DJB's software. Don't forget to include positive commentary on the licensing and patch status.
Thanks!
...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 (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.
Most of the companies in the list are "Status: unknown".....
Monstar L
Recommendation is more CERTS, as they will help with the sand breath.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
This is from the advisory.
Filter traffic at network perimeters
Because the ability to spoof IP addresses is necessary to conduct
these attacks, administrators should take care to filter spoofedaddresses at the network perimeter. IETF Request for Comments(RFC)
documents RFC 2827, RFC 3704, and RFC 3013 describe best currentpractices (BCPs) for implementing this defense. It is important to
understand your network's configuration and service requirements
before deciding what changes are appropriate.
So...is this REALLY that serious? Is anyone NOT already doing this? I'm incredibly skeptical of big, sensational security alerts like this.
... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html
I'd of thought that, by its very nature, reverse engineering is never really directly possible. Sorta why it has to be reverse engineered.
1. Subvert DNS so doxpara.com == (malware site)
2. replace "DNS checker tool" with rootkit.
3. ???
4. Profit!
Comment removed based on user account deletion
What a terrible summary. What would be really useful and news worthy would be a link to a web page with some information about the vulnerability. The links in the summary included: 1) a WORD DOCUMENT? WTF? 2) a PDF, 3) a podcast?? WTF? and 4) a link to a slashdotted DNS checker. How about a link to the CERT vulnerability web page which describes the problem?
http://www.kb.cert.org/vuls/id/800113
Now THAT would have been much more useful. Do people who work as sysadmins actually have time to sit around listening to a podcast? Especially when there are DNS servers to patch?
Google Dan Kaminsky and come back and talk.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Its a problem in the protocol. So the only systems that would not be vulnerable are those that did -not- follow the specs. Guess Windows is safe, since Microsoft never follows the specs :)
No, but it is possible for a single vulnerability to affect every poor DNS implementation. From there you would be able to deploy OS specific attacks.
"I use a Mac because I'm just better than you are."
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.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
It is not that hard if it was a flaw in the design. The design said do this. Doing 'this' is now known to be bad. Hence the problem affecting everything.
I have been trying to pretend it was Friday all day!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Comment removed based on user account deletion
I would like everyone to know that mexican DNS servers of "Telmex" are vulnerable as of July 8, 2200 GMT. It would not surprise me if all DNS servers in mexico were vulnerable. I am not asking for an attack, but it would be nice to get some competent ppl @ ISP's in mexico :)
Do I trust it? I don't know. Tell me the facts. The sheer quantity of internet shenanigans going on of late makes me suspicious. This sounds like they're patching for a remote root exploit, but a protocol issue won't do that. DNS poisons? What is it then?
They're making us patch everything, and aren't telling us what it does. These are my systems, and you're going to tell me precisely what's going on before any of your code gets to run.
Hey -- building or patching executables opcode-by-opcode is a time-honored tradition among crackers, old-school virus writers 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90.
Here, patched that for you.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
from http://www.kb.cert.org/vuls/id/800113: "The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID."
Just put the real seed back into the code.
obrant: and who the frak releases advisories in DOC format in the 21st century?
The reason girls and Windows users don't understand UNIX is because all the documentation is in Man files.
That's been the major WTF for quite a while, considering that Perl has been doing UTF-8, natively, for ever now. WTF WTF WTF WTF?
Read the diffs to BIND and work it out. They're only hiding things from the bad guys to give you a few more hours window to implement the patches.. :)
...an Englishman in London.
Debian Security Advisory DSA-1605-1 Package : glibc Vulnerability : DNS cache poisoning Problem type : remote Debian-specific: no CVE Id(s) : CVE-2008-1447 CERT advisory : VU#800113 Dan Kaminsky discovered that properties inherent to the DNS protocol lead to practical DNS spoofing and cache poisoning attacks. Among other things, successful attacks can lead to misdirected web traffic and email rerouting. At this time, it is not possible to implement the recommended countermeasures in the GNU libc stub resolver. The following workarounds are available: 1. Install a local BIND 9 resoler on the host, possibly in forward-only mode. BIND 9 will then use source port randomization when sending queries over the network. (Other caching resolvers can be used instead.) 2. Rely on IP address spoofing protection if available. Successful attacks must spoof the address of one of the resolvers, which may not be possible if the network is guarded properly against IP spoofing attacks (both from internal and external sources). This DSA will be updated when patches for hardening the stub resolver are available.
Make it the MAC address and you don't need a separate unique part to install on the circuit board. The ROM with the MAC address need be the only custom device.
This is spooky as hell to me. Is it even possible for a single vulnerability to affect EVERY OS EVERYWHERE at once? That's uncanny, if it really is the case.
It is possible if it is a protocol level vulnerability, like this one is.... There is no bug, except that the protocol's design is flawed. The same thing happened when Microsoft disclosed a WMF vulnerability a few years back -- every compliant implementation had the same flaw.
What better way to create a backdoor into every computer network in the world. Now that all of the US companies involved have been assured they will have immunity.
The TLA's will never take me ali
Failure to follow this advice may result in non-deterministic behavior.
I've just been made aware of RFC 3383: http://www.ietf.org/rfc/rfc3833.txt dated August 2004.
Section 2.2 clearly discusses the "security flaw" that Kominsky "discovered" early this year.
The reason girls and Windows users don't understand UNIX is because all the documentation is in Man files.
... is not vulnerable ;-)
Cheers
If you haven't ditched BIND yet, this is a good opportunity to do so, since DJBDNS has been placed in the public domain. Otherwise, you'll be monkeying around with disruptive BIND patches for the rest of your life.
Its a problem in the protocol. So the only systems that would not be vulnerable are those that did -not- follow the specs. Guess Windows is safe, since Microsoft never follows the specs :)
I know you meant that to be funny, but the truth is, is that the "fix" that is being deployed is to randomize UDP port numbers. We will have to wait until August 6th to find out what the exploit is all about.
Vendors that don't implement proper randomization are just lazy. Don't buy/download there software.
It has been known for years, that it makes your DNS-implementation safer to use, they have been warned again and again. And now they needed a year to implement it.
New things are always on the horizon
It is known for years that it's less secure, if you don't use proper randomization. Now it turns out, it's _really_ insecure. Duh.
New things are always on the horizon
WTF
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
The exploit is trivial to figure out - if a caching DNS server has recursion enabled, and also sends the outgoing DNS queries to the authoritative servers over a fixed (or predictable) UDP port, you can just send forged UDP responses together with your recursive DNS query.
The bogus response will be cached and will affect other users of the DNS server.
The attacker also needs to also guess the transaction ID (16-bit value), but they can send multiple bogus UDP responses with different transaction IDs.
Also, vulnerable implementations may generate transaction IDs in a predictable way, so the attacker can obtain the current state of the PRNG by generating a recursive DNS query to DNS zone under attacker's control.
Such an attack cannot be performed from a typical home broadband connection, as most ISPs will not route packets originating from IP addresses not allocated by the ISP.
The attacker needs to be in control over the routing/egress filtering within his AS (e.g. an enterprise-level Internet service).
throw new SuccessException("Sig read successfully");
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.
It seems to me that this was the fifth-best solution. In fourth place would be just using TCP instead of UDP for all traffic. It's already supported in every existing client and server, we just need to deprecate UDP; it could be done today. This would make it far harder than simply enlarging the range of guessable numbers by a handful of bits.
In third place (which is what I'd really like to see) would be using TLS over that TCP, with server validation, plus optional client validation. This uses totally stock libraries that already exist on essentially every platform.
I'd like to preemptively address any performance concerns, by saying I don't care. This won't come close to clogging our precious tubes, and we're talking about cached results anyway, so don't bother complaining about one extra TLS/TCP set of handshakes every few minutes or hours. Security always has a price in terms of convenience, and this is it.
Has anyone else noticed that atleast Comcast and ATT Edge was hit very hard with DNS attack today. Porn websites took over every DNS query.
A good way to find out is to go directly to the CERT web site and have a look at the vulnerability note they're talking about. Link here, if you trust me =) http://www.kb.cert.org/vuls/id/484649/
Do not mock my vision of impractical footwear
and a nightmare at the same time for each and every intelligence service worldwide.
no one will get the patch because distros never package patches
That's one of the problems with binary distributions. FreeBSD sysadmins, OTOH, have only to cvsup or, if you don't even want to wait for that, edit the bind94/Makefile, change ISCVERSION from "9.4.2" to "9.4.3b2", run make makesum && make install clean, wait 3 minutes, and restart named.
But this bug also reflects poorly on ICS's Bind 9 development process. They could have reused bind v8 code which had already fixed these sequence randomization issues. Sadly, in their hast to reissue a "chock-full-o-features" bind v9 security took a back seat. Believe me this is not the only potential vulnerability in bind 9.
If you don't understand that, you don't need to care.
What's funny is that the CERT advisory gives Dan Bernstein credit for the work around, which he came up with over 7 years ago.
It's possible that there is more to this than what I have divined from the 'uber-secret-vendor-only' disclosure but this seems to be little more than traditional cache poisoning with random-number-generator (RNG) prediction. Both of these situations have been well known and documented within the security community for a number of years.
Cache poisoning was predicted long ago by Dan Bernstein (as mentioned by a previous poster or two)[1]. (Nobody listens to me either, DJB.) The combination of this and RNG prediction was wrapped up nicely by Joe Stewart in his 2002 (I think) paper [2]. Joe used Michal Zalewski's free TCP/IP sequence number prediction software [3] to visualize random number generator attacks on DNS responses from various resolvers. The paper is well worth a look if you made it through the last sentence and are still reading this one.
Incidentally, Paul Vixie (BIND author,) posted a potential fix to this (or a surprisingly similar) problem to the Namedroppers mailing list at the end of February [4]. Time will tell whether the two events are connected.
This whole saga appears to be another case of 'marketing department run amok' but we'll have to wait for the BlackHat presentation to find out if all of this is just regurgitated previously ignored security advice.
[1] http://cr.yp.to/djbdns/dns_random.html
[2] http://www.lurhq.com/dnscache.pdf
[3] http://razor.bindview.com/publish/papers/tcpseq/vseq.tgz (currently down)
[4] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00378.html
1. DNS (well, UDP protocols in general) problems have been known for ages. This is nothing new, it's just new because so much drama has been created. There is a reason why certain counter-measures have already been implemented in DNS software. Never mind that noone is using them because it requires effort.
2. So much focus has been put on "phishing". I'd like someone to explain me how phishers are going to forge certificates and get sensitive info? Sure, I'll get bogus IP for the website I want to visit, but unless phishers manage to create valid certificate for gmail.com (for example), I'll get a nice warning box. Which is the same shit as what is happening now, when you go to a phishing website. Those who click "Ok" on every prompt will still get fucked, those who check errors will still not be tricked. Nothing changes.
3. Security became a joke when advisories like "Man in the middle attack allows attackers to steal Myspace passwords" started showing up on first pages of various news outlets.
It's not necessary, I think, to read the diffs. The CERT advisory describes the problem quite nicely - it's just another instance of "randomness? I'll always return 7 - it's as good as any other number" problem that allows one to spoof TCP connections with some stacks.
I'm a haiku hunter. Trophies are displayed here.
As a final project in a security course, a friend of mine and I wrote a tool which attempts to detect some of the problems mentioned in the CERT warning. I've posted it at http://github.com/lutzky/fatns
Well Microsoft forgot to tell Checkpoint to change Zone Alarm. Loaded the Security patch this morning and after reboot I had no Internet Access. Figured out the problem by checking the firewall logs. Shutting off Zone Alarm and switching to Microsoft's firewall sorted this issue immediately. The Zone Alarm website seems to indicate that this problem only occurs with Windows XP and that Vista is not affected. There will be a lot of people who will not have a clue what has happened.
Name: NLnet Labs Status: Unknown Date Notified: 2008-05-14 10:21:07 Statement: Unbound implements numerous strategies _to prevent spoof protection_ :D
Users of zonealarm are being left vulnerable and either have to leave the patch uninstalled or turn Zonealarm off!
You bump ZoneAlarm down one level, from Internet High to Internet Medium and that fixes it. Will be a tough problem for many though, as once you're offline you can't research it and MS & ZA can't push a fix.
From this posting: "DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use."
But I'm sure his acting like a jerk still means that nobody should ever take his criticisms of software design seriously. Heck, the BIND folks didn't, and it's not like people are going to stop using BIND.
Laws do not persuade just because they threaten. --Seneca
I'm sure the half-dozen people who are actually using IPv6 right now are terribly devastated by that.
Wait, no, there's not even that excuse. There's a patched version--since djbdns is now public domain, you can just grab Debian's dbndns package, which includes IPv6 support.
Laws do not persuade just because they threaten. --Seneca
Here's a description of pretty much the same attack, with pretty much the same solution recommended, back in 2001: http://cr.yp.to/djbdns/forgery-cost.txt
Laws do not persuade just because they threaten. --Seneca
DNSSEC proposes a single point of failure for the security of the entire DNS system, and this is widely considered a good idea? How did that happen?
Not to mention that the current X.509 infrastructure as deployed in web browsers checks neither CRLs nor an OCSP service by default--good luck revoking a mistakenly issued DNS signature, especially when instead of a few cert checks per day, each and every client is doing possibly hundreds. And this is supposed to magically scale up? You'd have better luck getting everyone to run the whole system over TLS.
Laws do not persuade just because they threaten. --Seneca
Since djb released djbdns into the public domain earlier this year, Debian, at least, is distributing a package called "dbndns" with the IPv6-enabling patch included.
Laws do not persuade just because they threaten. --Seneca
As djbdns is now in the public domain, Debian provides dbndbs, which supports IPv6 out of the box.
Laws do not persuade just because they threaten. --Seneca
I work at a large university, which supposedly has security staff. They're running BIND 9.3 (I think--nmap -A says "ISC BIND (Fake version: 9.3.1)"), and they're vulnerable. I sent a note to the security staff, but haven't gotten anything back yet. They're serving less than a hundred zones--or were, when the status page was last updated during the Clinton Administration--so I can't imagine they'd have a performance problem with the patch. Perhaps they're busy reading our email and sending nasty letters to BitTorrent users.
Laws do not persuade just because they threaten. --Seneca
All your DNS Cache are belong to us!!!
Don't you mean "66.102.9.147 Dan Kaminsky"?
ZA suggest that keeping Zonealarm on high and not (yet) installing the MS patch is the better option:
http://forum.zonealarm.com/zonelabs/board/message?board.id=cfg&message.id=52862
In course of RU-BIND development I researched an issue something around 14 years ago (1994). After some discussions with Paul Vixie in 1995 I decided that problem is mostly overblown. To reach a success an attacker should do something very unreliable and a lot of lack:
1. Attacker should know what NS records cache server knows. Specificly, attack goes nowhere if cache server has a record. That means that attack is useless for popular sites and can be done only for unpopular sites which has a very short reference from root or .com server. It still has sense to hide identity.
2. Attacker should know which root server or another authoritative server would be used by cache server. It is practically possible for handfull cache servers only or for 3rd level domains (something below company.com)
3. Any activity on cache server actually disrupts an attack. To reach the success an attacker needs to send a couple forged responses with a specific response ID. In regular BIND response ID can be calculated UNTIL there is a traffic. In case of traffic it is needed to send a couple of responses with sequence of IDs. The most of Linux hosts limit the unprocessed UDP queue to 1000 packets only, but not 64K. Any unprocessed packet which exceeds 1000 will be discarded.
4. Attacker has a one chance per domain name per server. He can repeat it only after TTL expiration. Yes, it is short for popular sites but BIND restricts it to 5min minimum. And that has much much more value (12h typical) for overseas countries.
5. Attacker should explore DNS space before attack - what fills a local cache server with records, so attack has sense for remote cache servers only. But remote cache server has a shorter distance to authoritative server, so the arrival time of forged responses is difficult to calculate.
So, the success chance is very slim. Attacker is restricted by 3rd level domains, overseas countries and remote cache servers in most cases. Under that it has sense only to hide identity behind some overseas domain.
After that I implemented a simple cryptographic ID conversion of 16bits ID in RU-BIND (Russion BIND version) and calculation shows that it dramaticly decreased the chance of an attack success, something which can happens in couple of years. Taking into account a verification of server responsibility (I listened it was implemented later in regular BIND too) it effectively nullifies the chances of attacker to poison a cache.
What's even more funny is that everyone has known about this issue for a long time, and most DNS products already protect against it. The only story here is that MS, Cisco, Juniper, Bind, and Nominum finally wrote patches for it. It would be great if the summary was updated, because this,
is pretty fucking misleading.
These are my systems, and you're going to tell me precisely what's going on before any of your code gets to run.
So don't trust it. You're already running their code and you seemed quite happy to do so without them telling you precisely what potential bugs could exist. Why get so demanding now?
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
I understand that djb draws a lot of flack for being a legendarily caustic personality; I'm just a little bitter that the sensible parts of his advice get ignored as well. DNSSEC is an implausible mess with a single point of failure, IPv6 migration is a joke, and DNS without source port randomization is vulnerable to spoofing. Despite his other, wackier beliefs (a new format for FTP listings! a new format for mail transfer! blasting mail across parallel connections instead of one connection per server just because I like it that way!), there's some important stuff in there.
Laws do not persuade just because they threaten. --Seneca
Reading the diffs doesn't help. The diffs randomize the source port. But the question is -- what's the problem if you don't randomize the source port?
There is no way to tell if our systems actually have a vulnerability. There is no obvious reason you should need to randomize the source port.
In fact, it's really unclear why randomizing the source port alone would do anything. Anyone who can send a single fake reply can send 10,000 fake replies to different ports.
...we don't even get to blame Microsoft for this one. The list of vendor who need to be patched is LONG!
Anyone who can send a single fake reply can send 10,000 fake replies to different ports.
Not if you already need to send 10000 (or 1000, or 100...) fake replies to guess the transaction ID.
Its easy, don't use bug BIND and all clones. ( MICROSOFT IS A BABY BORN in ILLEGAL PRACTICES AND BAD ENGINERING IF YOU COMPARES WITH BIND, mafIAA is a KID near them).
Its easy, don't get out rfcs.
Its easy, don't put a 18y boy that agree to do a job of a guy that study for 5y and receive tousands dollars month.
Its easy, Treat the network like a mechanical engineer or a structural one, and not like something i read in a tutorial and do work.
Its easy.
Its easy, network and all structure, is not just a network card, or a wifi card and a windows conf with a beuty new ASDL/CABLE router. ITS a science, its complex. ITS something need to be engined. Not done for a CURIOUS or companies that do DUMB things. Home users dont need know ever what and why they use DNS, like they don't know and why they use a Tiristor, or a fusistor, or a BALDRAME BASe or a Thermodynamic that a car motor use to work.
Think that network is a serious thing that now, everyone thing to be INTERNET.
Start this and your company will start have the troubles that a well engined company have.
Troubles and bugs en problems exist, but if you have a rule and you are straight in this rules ( RFCS), its easy and more simple to find, solve and deploy. Not this monkey like kid they are done.
See, so this companies and this guy will SOLD a program that correct this and everyone will understand this marketing.
About DJBDNS. Well, why support native IPV6? will this be a stand art someday of something?
and if you want this, just use a small path and this work.
Think DJBDNS a base, simple, small and stable code ( for years, without a problem). If you want to do something like IPV6 or IXFR ) Patch IT and will work like a charm, for years, and you will forgot this exist in your network, until some windows or bind invent something new to mask a bug and put a kind of out rfcs incompatible thing)
Now think about microsoft and BIND, if you want do something, you cant, because the DNS program is by itself a complex piece of SHIT that everyone use and need 29 companies and all engineers together to understand what this ( old and well shit, like another thousands ones ) mean.
Well it this.., good luck for everyone under this PROBLEM.. really, GOOD GOOD LUCK.
And besides the comments here..
Sit and relax. After this all be reveled and a magic program that will be SOLD. Ask a cheap 15y old boy taht rad a beauty HOWTO on internet to do the job for you and your BIG MULTINATIONAL COMPANY.
Why worry.?
This way work before, will work now again. :-)