Despite the best efforts of the security community, the details of a critical Internet vulnerability discovered by Dan Kaminsky about six months ago have leaked. Hackers are racing to produce exploit code, and network operators who have not already patched the hole are scrambling to catch up. The whole mess is a good illustration of the problems with researching and disclosing flaws like this.
The details of the vulnerability are not important, but basically it is a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 22.214.171.124. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com – there is no way for you to tell the difference - and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.
Here is the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There is a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On 8 July, he held a press conference to announce the vulnerability – but not the details – and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the Black Hat conference early next month.
The details leaked
Of course, the details leaked. How is not important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I am kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.
What is the moral here? It is easy to condemn Kaminsky: if he had shut up about the problem, we would not be in this mess. But that is just wrong. Kaminsky found the vulnerability by accident. There is no reason to believe he was the first one to find it, and it is ridiculous to believe he would be the last. Do not shoot the messenger. The problem is with the DNS protocol; it is insecure.
The real lesson is that the patch treadmill does not work, and it has not for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process will not prevent every vulnerability, but it is much more secure – and cheaper – than the patch treadmill we are all on now.
A particular mindset
What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It is not that he discovers all possible attacks before the bad guys do; it is more that he anticipates potential types of attacks, and defends against them even if he does not know their details. I see this all the time in good cryptographic designs. It is over-engineering based on intuition, but if the security engineer has good intuition, it generally works.
Kaminsky’s vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomisation was a smart design choice. That is exactly the work-around being rolled out now following Kaminsky’s discovery. Bernstein did not discover Kaminsky’s attack; instead, he saw a general class of attacks and realised that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, does not need to be patched; it is already immune to Kaminsky’s attack.
That is what a good design looks like. It is not just secure against known attacks; it is also secure against unknown attacks. We need more of this, not just on the Internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.