I came across an interesting article while reading Information Week magazine. It was entitled “DNS Threat revealed”. The details of the threat were not being revealed until people got a chance to apply a patch. However the high level description was that the transaction ID was not random enough in TCP/IP packets. Unscrupulous individuals could use this weakness to reroute requests to other web sites. The article stated that most Windows PCs that have auto updates turned on should be safe by now. This hole was first discovered by Dan Kaminsky of IOActive.
It seems that other trade presses were reporting this same story. I obtained a lot more information from a Network World magazine article online. An alert about the problem was issued by the Computer Emergency Readiness Team (CERT), which is part of Homeland Security. I further found that Dan Kaminsky’s official title at IOActive is “Director of Penetration Testing”. The patch for the problem was released on July 8th. There was impressive multi-vendor coordination due to the severity of the weakness. If the problem was not patched, it could have led to web outages.
I benefited by reading the original alert issued by CERT. It labels this weakness “Cache Poisoning” or Cache Pollution. It did not come out and say it, however I think the TCP/IP transaction ID field which is problematic is actually named TXID. The TXID is a 16 bit field. However some DNS implementations were not using the full 16 bits, making it easier to spoof the numbers.
Kaminsky got kudos from the black hat community for his responsible disclosure of the weakness. It seems he could have sold this information to evil hackers for a large sum of money. I hope this gives the guy some credibility. Since he did not initially come out and provide all the details of the bug, it was hard to tell whether the problem was just a lot of hype. However it seems that the select few who got the details so they could develop patches took the guy seriously.
Use the Requirements Already - I am working on a release at work. Initially we were supposed to replicate some bunch of database tables that the customer had in an old system. We did a ...