It seems I wasn't the only one to point out, in a comment on your earlier story, that DJB warned very clearly of this in 2001.

From the Colour out of Space:

"It was really lucky for Ammi that he was not more imaginative. Even as things were, his mind was bent ever so slightly; but had he been able to connect and reflect upon all the portents around him he must inevitably have turned a total maniac. In the twilight he hastened home, the screams of the mad woman and the nervous child ringing horribly in his ears."

I mean jesus, there have been command line tools to play with this in the wild for over eight years, running around pretending like it's some big secret just makes me think of a Benny Hill closing sequence.

Only without the tits, oh, no, wait....

@Tom Kelsall : Spot on there.

This was one of the many issues I noted in a 2000 report on DNS. ICANN stated my "study was flawed" and got the lawyers involved.

http://news.cnet.com/Security-firm-warns-of-outdated-software/2100-1023_3-241876.html

http://www.zdnet.com.au/news/security/soa/80-000-Domains-at-Risk-DNS-problems-plague-Australia-/0,130061744,120101062,00.htm

If this exploit calls for the rogue to fire bogus DNS "responses" to (possibly unrelated) queries from the rogue's machine to the victim's, then wouldn't turning DNS over to TCP exclusively go a long way toward closing up this hole?

Presuming we're talking about a victim's machine that has not already been compromised in some way, the query and response travel over a connection which must be established between the user's machine and a machine at the IP address to which the user's machine sent the query. Unless the man in the middle can proxy the victim's queries by impersonating name servers at any arbitrary addresses over the net, which implies more or less complete complete control of the victim's routing, the most he can do is observe the traffic, but not monkey with it. Or am I mistaken?

TCP does mean more overhead, but that may be a reasonable price to pay to avoid this problem. It may also be possible to restrict DNS to TCP only where attacks like this are possible, leaving trustworthy networks free to use UDP in the conventional way. I don't think the extra time to an end user whose workstation is querying DNS only by TCP is going to amount to much.

Tux, just because.

How many "End users" are using a proxy... and where does the proxy do lookups?

if the "proxy" is force-feed by a man-in-the-middle an incorrect IP for a name....

Hello to mass-drive-by-downloads with pass-through to secure sites still possible,

more than being a man in the middle... it becomes a proxy vulnerability too readily,

just *knowing* the proxy IP is enough and then it becomes a static heartbeat to push the false address... when any end-user on that proxy uses the false address...

Hello can, Hello worms... oh... time for some fishing I see...

by which time... already it is too late for the storm on the vista...

Fun and games...

Whilst "turning DNS over to TCP exclusively" might go a little way toward closing up this hole its far a practcal solution because it has the potential to open up many more possible exploits, increase the cpu and bandwidth on the server and slowing down the internet experience for everyone.

In my understanding it follows that if the UDP transaction ID is predictable, the default TCP transaction ID is likely to follow suit, thus it is still vulnerable, allbeit to a slighlty more sophisticated attack.

Better to come up with a fix that a workaround.

The basics of this attack and the possibility of it, were known about in 1995:

<quote>
With only 16 bits worth of query ID and 16 bits worth of UDP
port number, it's hard not to be predictable. A determined
attacker can try all the numbers in a very short time and can
use patterns derived from examination of the freely available
BIND code. Even if we had a white noise generator to help
randomize our numbers, it's just too easy to try them all.
</quote>

The fact is, a lot of stupid software writers didn't even bother to try and be random, which only makes the problem easier to exploit, there's nothing new here.

This is not the same exploit as that discovered by Dan Kaminsky, as will become apparent when the details are revealed in August.

The exploit detailed in this paper is the well known brute force attack that has been seen in the wild for 15+ years and was completely understood when this paper written. Many firewalls and sysadmins are prepared for brute force attacks like this and can defend against them

The Kaminsky attack has a clever twist so the brute force element is not needed, which is why it is so important to patch your nameservers against it.

BTW The one and only real solution to any DNS spoofing exploit is DNSSEC. Time to start taking it seriously.

Neither of those posted links discuss DNS cache poisoning attacks, based on sequence prediction, they discuss the root servers running old versions of BIND. Were they somehow supposed to be relevant? If so, how?

I hope nobody is surprised at this... an awful lot of design and code is undertaken with more than half an eye on the deadline and budget. This sort of compromise is probably made on a daily basis across the software industry.

Have we forgotten the lesson of Y2K already? People will always take short cuts in design and development, either on basis of cost, or because "it'll never happen, that';s really unlikely". I imagine that this particular issue arose because the design in question was formulated without appreciating the long-term potential scale of the problem. Just like Y2K in fact - people thinking that the software just won't be in use within a few years and "we can cover that issue off next time"...

Plus ca change...

Oh but there has - its quite a common Hollywood plot - the old Madwoman in the Attic plot - plus all the numerous remakes of Jane Eyre.

Oh - hang on - are you talking about the the DSN thingy?

I'm still locked up here!

At least they've finally let me have a computer, so I can commune with fellow attic dwellers.

Fellow attic dwellers include the M$ Vista development team...

Come one, someone was going to say it. OK, coat got.

patched all my BIND systems within minutes of the notification - thanks to a streamlined system that was instigated a long time ago over fears of a new major problem with BIND - same with ISC DHCPD too. i'd love to move to something more more security... but i dont see DNSSEC being properly taken up widely for years and years to come :-(

I am interested in seeing if there is anything REALLY new from a number of the following:

Schuba, C., "Addressing Weaknesses in the Domain Name System Protocol", Master's thesis, Purdue University Department of Computer Sciences, August 1993.

Bellovin, Steven M. (1995) "Using the Domain Name System for System Break-ins" pp.199-208 in Proceedings of the 5th USENIX UNIX Security Symposium, Salt Lake City, Utah. Berkeley, CA: USENIX Association.

Bellovin, Steven M. (1989). “Security Problems in the TCP/IP Protocol Suite,” Computer Communications Review, 19(2):32-48.

R. T. Morris. A Weakness in the 4.2BSD UNIX TCP/IP Software. Computing Science Technical Report No. 117, AT&T Bell Laboratories, Murray Hill, New Jersey, February 1985

In particular, Schuba's work in the early 90's seems to address all the aspects mentioned in the July CERT release.

In the links above nothing is listed as these where articles on the paper. I did some tests in 2000 based on Schuba's paper and a couple newer cache poision attacks. As there were many servers taht where vulnerable to root level compromises nothing came of the cache poisioning.

I ran a test earlier in the year where I again tested versioning and found over 16% of the tested systems where so old as to be vulnerable to remote compromise. I see this as a far worse situation even if most of these are on the proverbial outskirts.

> How come there hasn't been a massive exploit of this, potentially lucrative flaw?

Oh but there has been. It's called "pharming". Been going on for years.

The secret shortcut Mr. Kaminsky has "discovered" is simply that you can rather easily get the source port used for queries, because it's unchanging. That reduces the problem to the query ID, which in some vulnerable implementations is entirely predictable (bad entropy algorithm). At best, this is a 16-bit random number - how secure is 16-bit crypto?

> i'd love to move to something more more security... but i dont see

> DNSSEC being properly taken up widely for years and years to come :-(

It's coming, and fast. Implementation at the TLD level is getting closer and closer - at least 4 TLD's are now signed, plus some parts of in-addr.arpa. The new DLV service offered by ISC and others makes even the lack of signing of TLD's less of a barrier.