TCP Flaw An Abject Lesson On Responsible Disclosure

The pendulum swing between responsibly disclosing a vulnerability privately to affected vendors so they can create a fix versus telling the world so IT can be aware of potential problems is swinging back into the vendors' favor. The result is that without public awareness, vendors aren't motivated to institute fixes on a timely basis.Dan Kaminsky tried to walk a fine line between responsible disclosure and getting end users to patch their systems while not releasing relevant details of the DNS cache poisoning vulnerability. His rationale when CERT made the cryptic announcement on July 8 about the DNS issue was that once the patches were available, organizations would still need time to test and deploy them.

Chances are, criminals who knew the details of the vulnerability would figure out a workable exploit long before patches were deployed, leaving organizations unnecessarily exposed. Kaminsky mentioned that a few people who figured out the nature of the DNS caching problem approached him privately with details after July 8. By July 22, the cat was out of the bag long before Kaminsky was going to reveal the details at Black Hat in August. In between those times, there was much hand wringing, finger pointing, and accusations of sensationalism.

That brings us to Sept. 30 when Robert Hansen, a.k.a. RSnake, and others alerted us to an apparent problem in the TCP/IP protocol discovered by Jack Louis of Swedish security firm Outpost24. Short on details but long on explanations, Louis and Robert E. Lee, CSO of Outpost24, in an interview describe a new denial-of-service attack that leverages a flaw in TCP. Lee and Louis will be giving a presentation at the Finnish conference T2, giving a technical history of TCP, and explaining what the attack is NOT. They won't be releasing any details, however.

In an interview I had with Lee, he said Louis found this issue in 2005, but the company shelved the information while it worked through an acquisition by Outpost24. It was a gamble that paid off -- no one else seems to have discovered this class of flaws in TCP. Lee, who has been a vocal proponent of Full and Immediate Disclosure, determined no one would be helped in knowing the details about the attack except the criminals.

Unlike application or problems with specific application protocols, knowing the nature and extent of an attack may arm organizations with the knowledge to decide if they want to continue to offer the service to others. In this case, the nature of the problem is so widespread and so fundamental to TCP that, without a useful workaround, disclosing the details would do more damage. The only option to stop this particular attack today is to block traffic from offending hosts. There goes the Internet.

In coordination with the Finnish CERT team, they contacted a number of vendors about the problem but weren't getting much response. Once the announcement was made public, Lee, during our late-night interview, said he was kept pretty busy talking to vendors about the problem. Let's be clear: Once the problem was made public, vendors took notice. It's déjà vu all over again.

Full Disclosure/Responsible Disclosure Argument Is Far From Dead

First there was BugTraq, the mailing list, where security vulnerabilities were released to the public with full details and working code, usually with little or no notice given to the vendor(s) affected. This was in response to the fact that when problems were reported privately to vendors, they would ignore or sweep the issue under the rug, taking months or years to come up with a fix, if ever at all. In most cases, vendors simply didn't have the processes to deal with security issues, so they treated them like regular bugs to be fixed whenever convenient. That was unacceptable, and the only way to force a vendor to fix security problems was to publicly rub them in their faces. The L0pht even made the mocking tagline "Making the theoretical practical since 1992" when Microsoft responded that a vulnerability was "theoretical." The folks at the L0pht showed them differently. The full-disclosure tactic took a few years to finally get recalcitrant vendors to pay attention.

Fast-forward to the late '90s when Microsoft and other vendors are getting pummeled in the press. By 2001, John Pescatore from Gartner is telling organizations to stop using Microsoft's IIS Web server. In 2002, a draft proposal, Responsible Vulnerability Disclosure Process, is submitted to the IETF only to expire. Responsible disclosure, the idea that researchers work with vendors before going public, is picking up steam. Lots of gums are flapping. By this time, most major vendors have set up their own response systems to deal with vulnerability notifications.

But the pendulum swings to both extremes. The time from notifying vendors of security problems to creating a patch is taking a lo-o-o-ng time and that gap seems to be growing. Vendors are exerting more control. Worse, services are cropping up to provide subscribers with advance notice of problems. Outright selling of working exploits is becoming a sustainable business model, and not just on the black market. Outpost24's Lee said that another vulnerability their researchers disclosed on the Full Disclosure mailing list this summer could have netted as much as $10,000 from a legitimate vulnerability reporting service. The upshot being that a few select individuals or organizations are more likely to have working exploits before vendors can provide patches. Without vulnerabilities being in the public eye, vendors can take more time fixing them, to the potential detriment of their customers.

I would hate to see the pendulum swing too far in the vendors' favor, allowing them the ability to exert excessive pressure on vulnerability researchers to keep problems quiet while organizations and individuals are exposed. I know that coming up with a software patch for a vulnerability and testing to ensure that it works and won't break other functionality is costly, but doing so is necessary.

It seemed that by the turn of the century, most major vendors got the message: Take vulnerability reports seriously; dedicate resources to create fixes quickly; everyone wins. Lee simply went public because he wanted to raise awareness because he wasn't getting a satisfactory response from vendors. Apparently his gambit worked. It's too bad he had to raise a public alarm to get any action.

Letting critical vulnerabilities languish until there is public knowledge is irresponsible.