Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Kaminsky DNS Bug Claimed Fixed By 1-Character Patch

kdawson posted about 6 years ago | from the but-it's-the-right-character dept.

Security 120

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."

cancel ×

120 comments

Sorry! There are no comments related to the filter you selected.

What about other DNS servers ? (5, Insightful)

neonux (1000992) | about 6 years ago | (#24792727)

If this is indeed not a protocol flaw, how come the same vulnerability is present on other DNS servers as well ?

Do they all use the same code from BIND for this particular 'feature' ?

Re:What about other DNS servers ? (5, Informative)

larry bagina (561269) | about 6 years ago | (#24792805)

There is a small window of time when a malicious record could be cached by ANY DNS server. (Port randomization makes guessing the correct port to hit much harder) Bind (and only bind) has/had a huge fucking bug that opened that window of time.

Updating non-expired records? (1)

mi (197448) | about 6 years ago | (#24796707)

But what if I really want to change a record, that hasn't expired yet? Will the fix force me to live with the old values until they expire?

Re:Updating non-expired records? (2, Insightful)

tsalmark (1265778) | about 6 years ago | (#24797883)

I don't think hacking every DNS server has ever been the solution of choice. Maybe updating your record and serial number, then reloading, if needed, the authoritative server. And the ones you don't control, well wait.

Re:Updating non-expired records? (1)

mi (197448) | about 6 years ago | (#24798037)

And the ones you don't control, well wait.

This means like a functionality loss to me — if I've made a mistake, I can't correct it until TTL expires — and I could before the "bug" was fixed...

Re:Updating non-expired records? (1)

MikeFM (12491) | about 6 years ago | (#24798111)

So don't keep your TTL so high? On the other hand we changed from a T1 to a fiber line the other day and all our IP addresses changed. It's been a nightmare trying to get them changed properly. I had them preemptively set to a low TTL for a few days to give things time to clear from cache but we still are getting weird fluctuations. Some servers are showing the old addresses still more than a week later. Some are alternating between the new and old address. Some have just decided to give addresses that are just plain wrong. I've never had this much trouble before.

I was wondering if bad fixes for this DNS poisoning crap are causing DNS servers to behave badly.

Re:What about other DNS servers ? (3, Interesting)

Anonymous Coward | about 6 years ago | (#24792933)

Bind is effectively the reference implementation, so probably, or they made the same mistake at any rate. That's not surprising, this is a very subtle bug that requires knowledge of the Kaminsky attack to recognise. It's worth pointing out however that djbdns had source-port randomisation from the start as a defensive measure, and thus remained very resistant to this attack.

Re:What about other DNS servers ? (4, Informative)

gclef (96311) | about 6 years ago | (#24792951)

No, this solution is basically breaking the DNS functionality that Kaminsky exploited. By design, the referral records were supposed to overwrite the cache (which some organizations do use). This patch breaks that.

Re:What about other DNS servers ? (5, Insightful)

B'Trey (111263) | about 6 years ago | (#24793367)

That seems accurate to me. After all, what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires. That may be preferable to a gaping security hole which lets attackers poison your cache, but I don't think it's accurate to call the issue a bug in BIND. I believe BIND was working as intended to allow updated records to overwrite older ones.

Re:What about other DNS servers ? (5, Insightful)

More Trouble (211162) | about 6 years ago | (#24793805)

After all, what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires.

You don't see that update until the TTL expires. That's why there's a TTL. If you're planning to make a change, lower the TTL well in advance to allow the new TTL to propagate.

Re:What about other DNS servers ? (2, Interesting)

Anonymous Coward | about 6 years ago | (#24795163)

+1 Insightful

This is what the DNS books I've read say happens. When I first started playing with DNS I was always surprised and could never explain why my updated records became active before the old record's TTL expired. Sounds like a bug that's been needing to be fixed for a long time now.

Re:What about other DNS servers ? (1)

Ungrounded Lightning (62228) | about 6 years ago | (#24797339)

... what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires. ... I believe BIND was working as intended to allow updatedrecords to overwrite older ones.

That's what I thought too, at first. It seems right to replace cahced records with newer ones. And perhaps that's why the code is written as it is.

But then I got to thinking: If the server has a cached record already, it wouldn't have asked for and update. So why is the new information there in the first place?

Re:What about other DNS servers ? (0)

Anonymous Coward | about 6 years ago | (#24794083)

Is that a feature or side effect. It sounds like its a side effect. Anyone requiring a non-published side effect for proper operation at any feat is likely to be disappointed in the future as there exists no requirement to maintain such a side effect.

It sounds like people need to come up with a better plan based on proper design rather than a side effect.

Heal me of my bitterness, oh Lord Messiah Barry! (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24793111)

Hosanna! Hosanna to the Lord Barry almighty!!!

Re:What about other DNS servers ? (3, Informative)

mrsbrisby (60242) | about 6 years ago | (#24793785)

how come the same vulnerability is present on other DNS servers as well ?

It isn't. djbdns [cr.yp.to] for example, is not affected. I don't think maradns is affected either.

Do they all use the same code from BIND for this particular 'feature' ?

Very likely.

BIND has a very permissive license; most other DNS servers exist to facilitate lock-in with a particular vendor's stack, or to push some enhanced feature set, so they'd be considered foolish if they didn't copy BIND's source code where they could.

If this is indeed not a protocol flaw,

Well, I'm not sure it is unfair to call this a protocol flaw. Maybe a design flaw.

BIND has resisted port randomization because "the RFC said so"- never mind that they wrote the RFC, and that no clients bother checking. Because it stopped spoofing attacks ten years ago, and it stops them today, most DNS servers- including those derived from BIND- do this.

BIND also uses these very complicated credibility rules for determining if it can override existing cache-knowledge. This can presumably save one or two queries per dot, but surely it would be safer to only cache answers to questions that were asked. That is, by the way, what djbdns does.

Most DNS spoofing attacks can also be solved by solving most blind spoofing attacks. There's a little reluctance to do so, because it makes things like DNSSEC largely obsolete for their intended audience. As a result, we see a lot of chest thumping and stomping in the temper tantrum. You can tell when you're about to get into one because they start by saying "If we just switched to DNSSEC by now, we wouldn't be having this problem."

Of course, since BGP peers now route-filter everywhere on the internet (they didn't used to!), mandatory source filtering is a completely possible and realistic way to stop this and other similar problems...

Re:What about other DNS servers ? (2, Informative)

wkcole (644783) | about 6 years ago | (#24796473)

If this is indeed not a protocol flaw, how come the same vulnerability is present on other DNS servers as well ?

Do they all use the same code from BIND for this particular 'feature' ?

No.

The /. description of that thread is inaccurate and the behavior of BIND in breaking trustworthiness ties (which are set up by RFC2181) in favor of apparently newer records is not a bug, but rather a behavior which has been operationally useful and normal for most of the history of DNS. If you look closely at Dan Kaminski's discussion of how he came to recognize the vulnerability, it becomes clear that he was using that normal behavior and put together all of the pieces of the attack from the fact that his experimental idea to enhance availability with spoofed DNS replies was working.

With the caveat that I'm trusting the posts on bind-users rather than looking in depth at the code in question, it seems to me that this change would restrict the defined functionality of dynamic DNS, which to some degree relies on resolvers treating new records as new rather than as forged, even if the TTL of a cached record from an equivalently authoritative (apparent) source has not expired. The way DNS changes propagate in practice would be modified significantly by this, and people who have gotten away with poor planning of DNS changes in the past would be hit harder by that sloppiness if the behavior of nameservers (BIND *and* others) is switched from giving ties to the new data to giving ties to cached data.

In the end, I think that there will need to be a new RFC on DNS extending RFC2181's discussion of cache/answer conflict resolution. IMHO the likely outcome of that will be a new model for conflict resolution that will make cache poisoning a bit harder while punishing authoritative servers for zones that either change a lot or are heavy spoofing targets with both load and a requirement of pedantic correctness. The only hope for resolving a conflict correctly would be to toss out every record between the root and the point of conflict and restart a recursive resolution of the conflicted names. That is a bit ugly, but not as ugly as simply switching the way the coin is flipped on cache/answer ties.

Steve Jobs (-1, Troll)

Anonymous Coward | about 6 years ago | (#24792731)

is dead. And Slashdot isn't reporting it. I guess that are too busy with the idle section.

Re:Steve Jobs (1, Informative)

morgan_greywolf (835522) | about 6 years ago | (#24792831)

is dead. And Slashdot isn't reporting it. I guess that are too busy with the idle section.

That would probably be because Steve Jobs is not dead [nzherald.co.nz] , though that never stopped them before, given BSD's "untimely demise". ;)

Re:Steve Jobs (1)

morgan_greywolf (835522) | about 6 years ago | (#24792843)

That would be because Steve Jobs is not dead. [nzherald.co.nz]

Re:Steve Jobs (5, Funny)

El Yanqui (1111145) | about 6 years ago | (#24793055)

Steve Jobs is alive and Slashdot isn't even covering it. This place blows.

Re:Steve Jobs (3, Funny)

bistromath007 (1253428) | about 6 years ago | (#24793279)

Forget that. Shouldn't we have regular updates on whether or not Charles Babbage is still dead? He's the father of computing itself, for fuck's sake!

Re:Steve Jobs (2, Funny)

Anonymous Coward | about 6 years ago | (#24793565)

Maybe we should have a Charles Babbage status page a bit like this one:
Abe Vigoda [abevigoda.com]

Re:Steve Jobs (0)

Anonymous Coward | about 6 years ago | (#24793531)

wait 6 or 7 months and then we'll see 3 or 4 dupes about how he's dead, how he isn't and how tragic it is that he died before he could vaporize psystar with his reality distortion field

Re:Steve Jobs (0)

Anonymous Coward | about 6 years ago | (#24797025)

Actually.... [slashdot.org]

Re:Steve Jobs (1)

GundamFan (848341) | about 6 years ago | (#24793593)

We need a site like this:

http://www.abevigoda.com/ffb.php [abevigoda.com]

for Steve Jobs... you know just to be sure.

I am start in the happy is (-1, Troll)

Anonymous Coward | about 6 years ago | (#24792733)

i am an indian and i smell like curry

OSS wins again (1, Troll)

UbuntuLinux (1242150) | about 6 years ago | (#24792741)

Once again Open Source Software displays its inherent superiority over closed source, proprietary solutions. If this software was written using a closed source, proprietary operating system, such as Windows Vista, this bug would still be in the wild and probably an order of magnitude worse. As it was written using an Open Source operating system, people have been able to inspect the source and find the fault.

Re:OSS wins again (4, Interesting)

somersault (912633) | about 6 years ago | (#24792995)

This has more to do with an oversight in the DNS standard - doesn't have anything to do with any single implementation. Windows, Linux, and any other networked system that uses DNS are equally affected.

Besides, it doesn't matter if your operating system is Open Source. You can write closed or open source software on any platform you want, and just because the source is available does not necessarily mean that bugs will be noticed and fixed. This situation just shows that even if there are no 'bugs' in an implementation of a standard, the original design may still be flawed.

I haven't been following this situation very closely, so perhaps I'm a bit off with the details, but I'd be happy for someone to put me right if that's the case.

Favouring cached DNS records seems to me to not be a spectacular idea for all situations. It depends on the length of the TTL setting on your DNS server though. I'm not sure what expiry time would be sensible for an ISP to use. You have to balance the fact that you want to up to date records with the amount of overhead that will be generated by all the DNS traffic.

Re:OSS wins again (0)

Anonymous Coward | about 6 years ago | (#24795553)

YHBT. YHL. HAND.

Re:OSS wins again (1)

somersault (912633) | about 6 years ago | (#24796123)

TY AC. BTW ILU.

Developer comments on the bug (4, Funny)

Anonymous Coward | about 6 years ago | (#24792745)

Ok! Ok! I must have, I must have put a decimal point in the wrong place
or something. Shit. I always do that. I always mess up some mundane
detail.

Re:Developer comments on the bug (1, Funny)

oodaloop (1229816) | about 6 years ago | (#24793019)

This is not a MUNDANE DETAIL, Anonymous Coward!

Re:Developer comments on the bug (0)

Anonymous Coward | about 6 years ago | (#24795539)

woosh

Re:Developer comments on the bug (0, Redundant)

dzfoo (772245) | about 6 years ago | (#24795757)

Fine. Now, chill out, here's my fix:

        / *
          * Rev. #1138 - 08/29/2008
          * DESC: Need to add one to not brake the intarnetS!
          */
        int idx; // idx = CURRENT_INDEX + 1;
        idx = CURRENT_INDEX + 2; // do nnot braek!!!!1one
        return = _cache[i];

And don't do it again!

        -dZ.

Not the first time! (2, Interesting)

supernova_hq (1014429) | about 6 years ago | (#24792769)

This is not the first time a huge security vulnerability was fixed by changing a single character!

From what I remember, the SSL vulnerability we saw a while ago was caused by a single excess comment mark (well, maybe two if it was a double forward slash

Re:Not the first time! (1)

morgan_greywolf (835522) | about 6 years ago | (#24792923)

This is not the first time a huge security vulnerability was fixed by changing a single character!

Yeah. I once wrote a web application and in one of the auth checks, I put a '==' where I wanted a '!='. Fortunately in that case one of the testers caught it and it never actually went to production, but sometimes we all make silly mistakes.

Re:Not the first time! (1, Insightful)

Anonymous Coward | about 6 years ago | (#24792973)

And if you used unit tests like a real developer you would had caught that simple error.

Re:Not the first time! (1)

Tridus (79566) | about 6 years ago | (#24793203)

Of course, because software that uses unit tests has never, ever, had a bug in it.

Re:Not the first time! (1)

Jellybob (597204) | about 6 years ago | (#24793325)

Of course it has, that doesn't mean that unit testing doesn't reduce the odds of you having a bug - especially one like that, where the test would almost certainly have flagged it up.

Your argument strikes me as being not unlike saying that locking your door doesn't stop someone breaking the front window, so why not just leave it open.

Re:Not the first time! (1)

Tridus (79566) | about 6 years ago | (#24793375)

And AC's argument was... what, exactly? "A bug got caught by the testers, therefore you don't use unit tests and are not a real developer!"

If someone is going to start with a completely inane statement, they're going to draw inane replies.

Re:Not the first time! (2, Interesting)

jellomizer (103300) | about 6 years ago | (#24793069)

There are a lot of bugs fixed by changing 1 character... It is a very common occurrence. Either you comment out a feature that isn't needed but causing a problem. Or change a default variable or a constant to a different value.
Eg origional code (Just making it up on the fly) of a possible security hole bug:

char x[9];
// x is populated by a char* variable
  for (register int i=0; i <= 9; i++) {
//doing some stuff on x[i]
  }

Now anyone with any C experience will realize that we have the possibility of an overflowed buffer. Now what is the fix, I see 2 of them that can fix the problem with 1 character change.
I could change = to by removing the =
or I could change 9 to 8 in the for loop.
Chances are for the most cases this code may go missed for a while, and the program will run great for years. Perhaps the char* input command limited they keyboard to 8 letters forcing the 9th to be null all the time. Then the code was changed to work for the web and its keyboard limit code was removed with a QuaryString value, without the check or the check stupidly done in Javascript or HTML maxlength. But still it is a security consern and can be fixed with 1 character and if you look at any CS 101 class you will see how common this error is. Espectially if they swap back and forth from VB to C

Re:Not the first time! (2, Informative)

sqlrob (173498) | about 6 years ago | (#24793107)

better change:

Remove the < *AND* don't use a hardcoded number, change to sizeof

Re:Not the first time! (0)

Muad'Dave (255648) | about 6 years ago | (#24794733)

...change to sizeof...

Which will return the size of a char * (pointer to character) on your system (typically 4 bytes), _not_ the length of the array. There is no way in C to get the length of an array after it's been allocated. Arrays are 'stupid' chunks of memory, not objects with properties.

Re:Not the first time! (2, Informative)

locofungus (179280) | about 6 years ago | (#24794935)

..change to sizeof...

Which will return the size of a char * (pointer to character) on your system (typically 4 bytes), _not_ the length of the array. There is no way in C to get the length of an array after it's been allocated. Arrays are 'stupid' chunks of memory, not objects with properties.

Huh?


char x[9];
printf("%d\n", (int)sizeof x);

will print 9 exactly as required.

There are a handful of cases where arrays do not decay to pointers. This is one of them.

Tim.

Re:Not the first time! (1)

mtdenial (769442) | about 6 years ago | (#24797089)

It's not the first time that any huge defects have been caused by a single character. Quoting Code Complete [wikipedia.org] who in turned was referencing an article from the early 80's (Kill that Code, Gerald Weinberg), "...three of the most expensive software errors of all time-costing $1.8 billion, $900 million and $245 million- involved the change of a single character in a previously correct program. So on the one hand, it's easy to sort of snicker that they were so close to having a correct implementation, but just missed, but on the other hand, there is a long and storied history of us programmers blowing things by a single character. I mean, isn't the 'off by one' error still one of the most common ones in development code, a instead of =, index instead of index-1 or whatever? At least now that the defect has been isolated and can be fixed. One character fix is much better than a full redesign...

Well let me just say (5, Funny)

beakerMeep (716990) | about 6 years ago | (#24792781)

(and I think for speak for everyone), this is how I feel about it:

!

No, it doesn't! (1)

CaraCalla (219718) | about 6 years ago | (#24792801)

It does not fix the case where the attacker first tries to poison aaaaaa.example.com, aaaaab.example.com, ... , fc4dss.example.com until he succeeds with the glue-record being the real evil. In that case there is no previous cache-entry to rely on.

Re:No, it doesn't! (1)

logru (909550) | about 6 years ago | (#24792897)

I would assume that is not a huge issue as af9ad.example.com is not a host that people would go to or anything would point to for that matter.

Re:No, it doesn't! (2)

CaraCalla (219718) | about 6 years ago | (#24793005)

It is indeed an issue: The injected record is trusted because it orgiginates from example.com, but the evil bits are in the glue record, which goes ahead hijacking the www.example.com record. Without really knowing bind, I assume the patch does not work in that case.

Re:No, it doesn't! (4, Informative)

quantumplacet (1195335) | about 6 years ago | (#24793685)

yes, the whole point of this patch is to fix this problem. previously, if i successfully passed a bad record for safdsaus.example.com i could send glue records for www.example.com that would overwrite your cached record for www.example.com no matter what. with this patch i can only pass bad glue records if the ttl on your cached www.example.com record has expired. this gives an attacker a very narrow window during which they could mount this type of attack, likely making it not worth the effort.

Re: No, it doesn't! (1)

not_hylas( ) (703994) | about 6 years ago | (#24796431)

I thought that bit had to be set if present - NO?

The bit field is laid out as follows:

                          0
                        +-+
                        |E|
                        +-+

Terminology

      The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
      SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
      document, are to be interpreted as described in [RFC2119].

RFC 3514 - The Security Flag in the IPv4 Header:

http://tools.ietf.org/html/rfc3514 [ietf.org]

Re:No, it doesn't! (1)

Magic5Ball (188725) | about 6 years ago | (#24795643)

It is an issue in the case of <img src="http://af9ad.example.com/whatever"> and related things that can load without active user intervention...

I call bullshit (4, Insightful)

Anonymous Coward | about 6 years ago | (#24792835)

Updating a cache with new data when the source data changes before the cached copy is a bug?

The "root cause" is being able to fake being the correct source of the data being overwritten, NOT the ability to refresh a cached copy.

And AFAICT, the ability to falsify data sources remains a FUNDAMENTAL flaw in DNS.

Re:I call bullshit (0)

Anonymous Coward | about 6 years ago | (#24797665)

Updating a cache with new data when the source data changes before the cached copy is a bug?

Before the TTL of the cached record has expired? Yes, it is.

Allegedly... (3, Interesting)

drmofe (523606) | about 6 years ago | (#24792853)

....Paul Vixie is no longer allowed to commit code to BIND. Can this vulnerability be traced to code that he DID write originally?

Re:Allegedly... (0)

Anonymous Coward | about 6 years ago | (#24795967)

no, bind9 was a rewrite.

A possible downside (3, Insightful)

js_sebastian (946118) | about 6 years ago | (#24792857)

From one of the mails of the guy who made this proposal:

What's the downside to my patch ? I guess we are now holding an
authoritative server to the promise not to change the NS record for
the duration of the TTL, which is kinda what the TTL is for in the
first place :)

I wonder if this is an issue. Otherwise it seems Kaminsky may really have missed the point.

Re:A possible downside (2, Insightful)

Ed Avis (5917) | about 6 years ago | (#24793007)

It does sound like an issue. Suppose an authoritative server responds to a query with a TTL of five minutes. That means it must not change the record during the next five minutes. After one minute the domain owner makes some change. Okay, there will be a lag of four minutes before it fully takes effect. Fine. But what if a second request is received a minute after the change? The authoritative server has to know that it has a change queued up to take effect in three minutes' time, and serve a reply with a TTL of three minutes or less. Moreover, it has to reply with the old version of the record, which is now known to be out of date. So internally it needs to keep track of old and new versions for each change, and keep serving the old version until the last TTL of a previous reply to that version expires. I doubt that all the various DNS servers across the net do this.

Re:A possible downside (5, Informative)

Anonymous Coward | about 6 years ago | (#24793289)

That's not how caches work. There is no guarantee that the authoritative server won't give out different responses until the TTL expires. The TTL just means that the resolver may cache the value for that duration. If the value changes during that time, the effect is just like when the server does DNS round-robin load balancing: This resolver uses a different value than other resolvers. Whether that is a problem depends on the validity of the resource, not on a server side decision to stick with an answer or to change it before the old value's TTL. When you change DNS records, you always keep the old resource up until you see only a low amount of requests to the old resource. There are way too many caches which ignore the server-defined TTL and use their own minimum TTLs.

Re:A possible downside (2, Informative)

berashith (222128) | about 6 years ago | (#24793395)

thank you!
A TTL is not a promise to never change the record. A true authoritative source can change and push new information. A TTL is an amount of time that a cached record can live before the holder of the cache needs to check back for new information, which is usually not changed.

Re:A possible downside (2, Informative)

mrsbrisby (60242) | about 6 years ago | (#24793857)

No, a true authority cannot push new information.

They would have to know all of the caches in order to push the changes to them, and since caches can cache for caches, it's unrealistic that a normal site could know this, and unlikely that a specially designed site would.

The cache should not cache answers to questions it didn't ask, and that includes new authorities for the domain.

Re:A possible downside (1)

berashith (222128) | about 6 years ago | (#24793953)

ok, yes, somewhat. I wasnt as clear as I should have been. All caches are not known, as you said, and DNS isnt a push system. But, there are cases of things like stealth masters that do keep track of all of its slaves, and these can tell the slaves to come look for new information. Not allowing updates to the slaves because of TTLs would create a non-needed time gap in propagation.

Re:A possible downside (2, Informative)

mrsbrisby (60242) | about 6 years ago | (#24794185)

But, there are cases of things like stealth masters that do keep track of all of its slaves, and these can tell the slaves to come look for new information. Not allowing updates to the slaves because of TTLs would create a non-needed time gap in propagation.

That's a terrible reason to allow such a large security hole.

You should have to list all of your ignore-ttl-from hosts, and src-filter communication to those sites before you should be allowed to do this.

That said, you could also use some other communication channel- such as the master sshing over to the cache and flushing the cache. Certainly that's safer and easier.

Re:A possible downside (3, Informative)

photon317 (208409) | about 6 years ago | (#24793643)

But that's not what the TTL is for in the first place. The TTL was not intended to mean "I will hold this record for this duration, ignoring any other updates in the meantime". It was meant to mean, "I will not under any circumstances remember this record any longer than this duration". The difference has practical implications for DNS operations.

Re:A possible downside (2, Informative)

QuietLagoon (813062) | about 6 years ago | (#24793793)

I guess we are now holding an authoritative server to the promise not to change the NS record for the duration of the TTL, which is kinda what the TTL is for in the first place :)
.

TTL does specify the Time To Live for a cached record before it is no longer considered to be valid.

TTL does not specify the length of time that changes are not allowed.

Server 2008 patch for this now out (4, Funny)

Anonymous Coward | about 6 years ago | (#24792861)

It's 570MB.

Re:Server 2008 patch for this now out (0)

Anonymous Coward | about 6 years ago | (#24795541)

570 MB?
Which Linux distro is that?

Not getting much love in the mailing list (4, Funny)

ccguy (1116865) | about 6 years ago | (#24792907)

I'm so bored that I actually read the post in the mailing list and all the replies in the thread.

Just to be at the same time informative and to the point, the 7 replies so far have been as positive as this patch [iu.edu] is in the linux kernel mailing list a few years ago.

Re:Not getting much love in the mailing list (2, Interesting)

Nigel Stepp (446) | about 6 years ago | (#24793273)

Ha! I feel like that is the same guy who wrote a text editor that runs in ring 0 or something and halts multitasking.

Anyone remember that guy? There was a huge usenet fight about it on some linux newsgroup in the 90s.

Anyway, he had exactly the same reasoning style.

Re:Not getting much love in the mailing list (1)

alx5000 (896642) | about 6 years ago | (#24793337)

Just to be at the same time informative and to the point, the 7 replies so far have been as positive as this patch [iu.edu] is in the linux kernel mailing list a few years ago.

OMG, is that guy for real?? I mean, I haven't still read through all of the replies, but... trying to un-UNIX Linux? Either he is one of the biggest morons to ever roam the earth, or he deserves a special place in the Trolls hall of fame...

Re:Not getting much love in the mailing list (1)

ccguy (1116865) | about 6 years ago | (#24793445)

OMG, is that guy for real?? I mean, I haven't still read through all of the replies, but... trying to un-UNIX Linux? Either he is one of the biggest morons to ever roam the earth, or he deserves a special place in the Trolls hall of fame...

Don't know, but after getting the old Al Viro's treatment he hid under a rock and I hear he's still there.

Re:Not getting much love in the mailing list (1)

Culture20 (968837) | about 6 years ago | (#24795037)

This guy was obviously trying to write the beginning stages of Ubuntu. Thankfully he settled on forking Debian.

Re:Not getting much love in the mailing list (0)

Anonymous Coward | about 6 years ago | (#24795955)

That patch is brilliant trolling work.

mmkaay (1)

amnezick (1253408) | about 6 years ago | (#24792917)

I'm not an expert so please ignore (or better .. explain) this if I'm way off but Google adives TTL 1 week when using their GoogleApps mail server. So .. what if I really really want to change my MX after 2 days? :-/

Re:mmkaay (1)

morgan_greywolf (835522) | about 6 years ago | (#24793001)

So .. what if I really really want to change my MX after 2 days? :-/

You can't. That's kind of the whole point.

Reminds me of the story... (5, Funny)

hanshotfirst (851936) | about 6 years ago | (#24792947)

(Source unknown)

A manufacturer had a problem with one of the older machines on their line. It shut down the line and held up production, costing many thousands of dollars in lost production. Since it was older equipment it was hard to find someone knowledgeable in repairing the machine, and nobody on-site knew what the problem could be. They found a technician with knowledge of the machine and hired him to come in and fix it.

When the technician arrived on site he listened to the client's description of the problem, examined the machine, opened a panel, and turned a single screw. He restarted the machine and it was back to full function. The line was up and running and the manufacturer was happy.
A week later the manufacturer received a bill for services: $1000. They called the technician and demanded an explanation - after all, they reasoned, he had only turned one screw to fix the problem. He agreed to re-bill, this time with itemized charges. The next bill contained two lines.

Turning the screw... $1
Knowing which screw to turn... $999

Re:Reminds me of the story... (1)

actionbastard (1206160) | about 6 years ago | (#24794605)

This is a derivative (or descendant) of a story that I read about a small town in Vermont. They had there own power generation facility for the town and it went on the fritz, plunging the small hamlet into darkness. The only person who knew anything about the machinery had long since retired, but the townspeople were desperate, so they they gave the old guy a call. He came out and took a look at the equipment. He then took a small hammer from his old toolbox and gently tapped on a certain point of the aged machine. It sprang back to life and everyone was greatful. A week or so goes by and the town council receives a bill from the old fellow for $10,000 itemized as follows, Tapping - $1.00, Knowing where to tap - $9,999.00. Of course, they paid the bill.
I read that story in an issue of Readers Digest more than forty years ago.

It's Charles Proteus Steinmetz: (0)

Anonymous Coward | about 6 years ago | (#24796863)

Steinmetz retired as an engineer from General Electric to teach electrical engineering at that city's Union College in 1902. General Electric later called back as a consultant. He had worked on a very complex system that was broken. No one could fix it no matter how hard the technicians tried. So they got Steinmetz back. He traced the systems and found the malfunctioning part and marked it with a piece of chalk.

Charles Steinmetz submitted a bill for $10,000 dollars. The General Electric managers were taken back and asked for an itemized invoice.

He sent back the following invoice:

Making chalk mark $1
Knowing where to place it $9,999

dynamic DNS (1)

Locklin (1074657) | about 6 years ago | (#24793047)

Is this going to break dynamic DNS services like redirectme.net?

Re:dynamic DNS (1)

chrysalis (50680) | about 6 years ago | (#24793189)

No, it has no reason to break dynamic dns services like redirectme.net

Re:dynamic DNS (1)

CyborgWarrior (633205) | about 6 years ago | (#24793285)

No. These services set very low TTLs in their entries so because they are known to change often (hence "dynamic")

NOT a fix... (4, Insightful)

nweaver (113078) | about 6 years ago | (#24793141)

This is NOT a fix to the root problem of the Kaminski vulnerability.

The root problem is the cases where athority/additional/unasked-answers are accepted, and there are plenty of variants this "patch" does not affect. EG.

Answer:
whatever.foo.com CNAME www.foo.com
www.foo.com A 66.6.66.6
Authority:
(usual goop).

If www.foo.com is not yet cached (and often even if it is), this will set it as a Kaminski variant.

Re:NOT a fix... (3, Informative)

blueg3 (192743) | about 6 years ago | (#24793313)

In cases where www.foo.com is not cached, DNS resolvers are vulnerable to the much more trivial attack of simply forging the answer www.foo.com IN A 66.6.66.6. Of course, they have to hope to guess the proper transaction ID in the first query, because if they fail, the proper answer will be cached.

Poisoning an uncached name is fairly easy and doesn't require Kaminsky's trick. Kaminsky's trick relies on caching the answers to questions you didn't ask, rather than not caching them or using the cached answer over the uncached answer. I think you called this the "elephant in the room" at Usenix Security, even. :-)

Re:NOT a fix... (1)

nweaver (113078) | about 6 years ago | (#24793379)

Well, Kaminski doesn't save packets over a normal race.

Its point is "Race until win" rather than "race once per TTL".

Thus in a normal race for www.foo.com, you can run the race once per TTL, and then have to wait if you fail.

With the kaminski race, you can keep running it until you succeed.

This is why Kaminski attacks are all about glue policy.

Re:NOT a fix... (1)

blueg3 (192743) | about 6 years ago | (#24793871)

Exactly -- and this patch causes you to prefer cached data over data supplied in glue records, yes?

Meh. (3, Funny)

Rob T Firefly (844560) | about 6 years ago | (#24793271)

Ever since seeng this [wikipedia.org] I don't trust that one character, Patch.

It was more than that. (3, Informative)

certain death (947081) | about 6 years ago | (#24793659)

They stopped random UDP port use, and now use a static pool of UDP ports for queries. Note that they have come out with a P2 release that addresses a completely different issue that the first patch caused. I was able to essentially cause a DOS on a BIND server that was patched with P1 by sending more than 10,000 queries to the system. It ran out of usable UDP ports and puked. The same issue exists in the Windows patch, and especially on Windows 2003 SBS. There was way more than one line of code, or a single character changed.

uh, have you also considered... (0)

Anonymous Coward | about 6 years ago | (#24793677)

Perhaps the people that came up with this as the "real fix" should consider the case when the NS records for a particular domain are not cached. There's not only a single scenario to consider when coming up with a patch, which is why defense in depth is important. This is not a complete fix without source port randomization.

What about DDoS? (0)

Anonymous Coward | about 6 years ago | (#24793899)

I'm probably missing something, but does this solution not impact an organization's ability to recover from varying DDoS attacks?

If I have to wait for all of my records to expire before I can shift my website from an IP that is being targeted by an attack, does that not leave me vulnerable for longer?

FAILZORS?! (-1, Redundant)

Anonymous Coward | about 6 years ago | (#24794569)

I'm sick Of it. [goat.cx]

May make it hard to have rapidly changing DNS (0)

Anonymous Coward | about 6 years ago | (#24794659)

Some rapidly changing domain names, used for things like Russian Business Network (and reputedly for frauds and so on) might be hard (harder anyway) to do with this patch, since old DNS records will tend to remain in force until their TTL expires. This might be a good thing, and at any rate it would make it easier to notice when a DNS resolution was perhaps suspect. Any DNS resolution that was going to change every few minutes would need a very short TTL which might be possible to ignore programatically.

Re: Should have been running NetReg (0)

Anonymous Coward | about 6 years ago | (#24794833)

in Managed and Monitored mode.

DNS (1)

Caspan (1323261) | about 6 years ago | (#24795613)

I didn't have time to read everyone's post here but the one thing I think everyone is forgetting or overlooking is why cache was created/used in the first place. 1st. Could you imagine the amount of extra traffic on the internet and core devices if every lookup had to traverse the net? It was designed because there is no need to change you DNS RRs constantly they should be static, or failing that only needed to be update once in a while. 2nd. what happens if my DNS serves go down (yes assuming both of them go) I can assume that at least some people can still find my service based on cached results from ISPs or root servers. Contrary to what I just said I also agree that the internet backbone is huge and could handle the extra traffic and maybe it is time to rethink old policy. just because its worked in the past dose not mean we have to continue to use it for the future. A lot has change since the first inception of the DNS RFC.

Kaminsky's rebuttal (4, Informative)

buelba (701300) | about 6 years ago | (#24795919)

Kaminsky has an interesting rebuttal here [doxpara.com] .

poisonous disinformation and ignorance (2, Insightful)

mibh (920980) | about 6 years ago | (#24796303)

i know of forms of poison that do not involve the authority section at all.

i know of servers with no BIND code inside that were poisoned by kaminsky.

i know of valid configuration changes that depend on NS RRset replacement.

is this a troll of some kind? as slashdot lead articles go, this one shows unusually high disinformation and ignorance.

What character? (1)

xouumalperxe (815707) | about 6 years ago | (#24796409)

Without even bothering to RTFA, I'm going to hazard that the patch was a '!' right before a '=' ;)

Re:What character? (1)

xouumalperxe (815707) | about 6 years ago | (#24796455)

Bah, managed to not only not RTFA, but misRTFS, didn't see it was an off-by-one.

Nice try, but no (1)

Effugas (2378) | about 6 years ago | (#24798117)

This is Dan Kaminsky, finder of the bug.

No, this isn't a reasonable fix. Nice try, but no. See http://www.doxpara.com/?p=1234 for details.

(Incide

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>