A Quick Thought Exercise on the DNS Debacle

For years, the vulnerability has been known. For years, the attack technique has existed. For years, the bad guys have had access to this method. Ask yourself this: what has changed that makes this so important right now? And try to get past the obvious, superficial answer. It might help you isolate on the true nature of this recent media blitz.

Now, think about all the other similarly complex protocols, software packages, etc. There will be similar vulnerabilities and attack techniques published in the future and you are as vulnerable right now. What are you doing about it?

6 comments for “A Quick Thought Exercise on the DNS Debacle

  1. Steve Pinkham
    July 26, 2008 at 12:46 am

    I take issue with the assertion that this has been “known” for years.
    There is no public comment or speculation on this particular attack strategy until this month. This attack strategy is new and different from anything we had previously.
    It is similar to old flaws, enough so that when you find out what it is it SEEMS like we should have know about it for years, but we didn’t.
    The interesting part to me is the head smacking simplicity of the attack, yet we all thought, “smart people designed this” and weren’t really looking for ways to abuse it. There are many other complex interactions which are getting reviewed by various security researchers who are going to have the next big story. We have far too many “ship it, we’ll secure it later” type application and protocols out there, and people who are skilled in security assessment have things to keep them busy for life.
    Another great point brought up by many is the fact that DJB protected against this vulnerability by doing everything he could come up with to harden the server in the first place. The reason DNS has had so many security problems is really because the security margin was so low to start with, any tiny crack breaks it. The lesson is security needs to be built in from the start, and good design minimizes risk down the road.

  2. July 26, 2008 at 4:44 am

    Pete,

    If you, personally, knew how to remotely poison DNS caches in 10 seconds, and did nothing about it, I’d think less of you.

    If you did not know how to poison DNS caches in 10 seconds, that’s OK. Neither did I, until recently, and I’ve been doing DNS in years.

    So, I think you’re probably OK.

  3. July 26, 2008 at 4:45 am

    s/in/for

  4. Pete
    July 26, 2008 at 7:38 am

    @Steve – I said the vulnerability – guessing random numbers to poison the DNS cached – has been known for years, not the attack technique. I was careful to also say that the attack technique has “existed” for years to point out that someone may have known about it for years (although I supposed it may have been infeasible with slower computers).

    Given that we knew there were ways to make DNS more secure, and elected not to, I would suggest it was “secure enough” until Dan’s big story. What I am also suggesting is that this notion is artificial and arbitrary.

    Pete

  5. Pete
    July 26, 2008 at 7:43 am

    @Dan -

    Using the word “personally” makes my point for me. This isn’t personal, it is about the cybersecurity of a billion people and 200 million websites. You think it is about you, but it isn’t.

    You say it took 10 years to figure out this threat, which significantly limits the population of people who could know about it (and prior to your news story, this was fine). Now you (and Halvar) says it takes a matter of days. What do you think the net impact is on risk, then?

    Pete

  6. July 26, 2008 at 3:28 pm

    Pete–

    I couldn’t agree with you more. The bug is not about me, or you, or anyone in the security community. It’s about all the people who are at risk and all the administrators who needed to do something to protect them. There’s a bug that’s been there for a long time. Some very bad people have likely been using it for a very long time to do very bad things. I could have just left it there. But, what you do not know is that there was a RFC in progress on Forgery Resilience. It posited that the way to protect against cache poisoning attacks was to have long TTL’s.

    The RFC was going to come out right about now, and the obvious rebuttal to the RFC is this bug. My attack would have been found quickly, and the attack would have spread like wildfire.

    So, we made up some story about why the RFC was being delayed (Bert’s wife was pregnant, this wasn’t hard) and got to work getting everyone to fix simultaneously.

    But it’s not enough to just release patches. In the real world, software needs to be deployed. Administrators need to be notified. So, we did what we could. I’d like to have done more. But I’m pretty happy with what what we did. You should be pretty happy too.

Comments are closed.