On Jul 14, 2008, at 9:32 AM, marty wrote: >> djbdns and PowerDNS are not vulnerable to this new attack vector >> because they don't hold open an outbound source port for queries. > DUH? Those authors realized the implications years ago, and > took precautions that render them invulnerable today. Just > because others ignored logic does not make this 'new'.
True, I agree, holding open the source port seems like an awfully silly self-inflicted wound. But we're seeing problems from the fix, too, in the form of too many file descriptors (open ports), as ports are held open waiting for a reply. Systems that get thousands or tens of thousands of recursive queries per second are having serious problems with the new BIND and MS DNS releases. I teach DNS theory. I've told my classes for years that BIND's behavior of holding open a single source port for queries seemed like a bad idea. And now we see why. It's unfortunate that the majority of the Internet uses the BIND name server for resolving name service, and not djbdns or PowerDNS. (In the case of djbdns, Professor Bernstein's general crackpot-seeming nature might have something to do with this.) But the glibc stub resolver is based on the BIND stub resolver code, and therefore I started this thread asking if this was going to be a problem for HLFS. >> The QA manager for CentOS, a friend of mine, told me that glibc is >> also vulnerable. > But he was referring to their glibc, not ours;O That is apparently true. And I am very happy to see evidence that the problem in glibc has already been addressed for HLFS. I don't think we can say for sure until the attack vector has been disclosed and any actual problem with glibc has been discussed publicly, but until that time, I will rest easier. > These 'revelations' only show the impact of rumors. Believe me, I was of the same opinion as you until Friday. I was sure that this was just the same old thing as before, and that Kaminsky was just grandstanding for the masses. Then the folks at ISC started contacting me in private and telling me a different story. > This IS the same old thing despite the newer codebase which > is affected, which adds more twists. Just because somebody > cracked a box in a lab does NOT constitute a good reason for > spreading alarm and panic. I think we will have to disagree on this until Mr. Kaminsky makes his exploit public. I don't have the facts of the exploit, only the evidence of some very concerned experts who've signed the NDA and seen the attack mechanism. > I don't use Microsoft products, or Distributions as servers. Here we are in agreement. > I don't even have a cache which can be poisoned. You're using a resolving name server somewhere. That resolving name server almost certainly has a cache. > I don't provide recursive DNS to the public. Does it provide recursive DNS service to anyone? To you? If so, your recursion restriction does not protect you. > My DNS server > will reject out of zone queries. The attack isn't based on queries, but rather on forged responses. I'm still having a hard time understanding what the attack vector could be, but people I trust who have been told (and can't tell me) have said that any resolving name server based on BIND from before the updates last week is vulnerable to a very fast, very effective attack, no matter how well-secured. The only protections are: - Disable recursion entirely. Forwarding is not a solution. - Upgrade to a patched version of BIND or MS DNS. - Don't use MS DNS or BIND for your recursion servers. > I don't need dnssec. Please explain your rationale for this statement. > Source ports are randomized by design in my software. If you use BIND as a resolving name server, the versions available before last Tuesday did not change their randomized ports between queries. > Everything is behind firewalls on Nat. And I use HLFS. None of that will help you in the slightest if you run a resolving name server based on BIND. > You are crying wolf again. Take a Valium. I am not crying wolf unnecessarily. (And why do you use the word "again"?) I said at the beginning of this thread that I had heard that stub resolvers were vulnerable also. If the HLFS version of glibc's stub resolver is already using random source ports, then that's great. End of story. The HLFS book does not include instructions to set up a DNS server. Then you asserted that this is the same old DNS spoofing attack (message ID guessing + port guessing) that we've seen for years, and I responded in an attempt to set the record straight. I apologize if my response was too verbose for you. However, as a DNS professional, I am concerned. Chris Buxton Professional Services Men & Mice -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
