|Submitted by mikeperry on Thu, 08/14/2008 - 18:31|
When I explain the completeness and the automated nature of my HTTPS cookie hijacking tool, the first reaction of many of my friends was to remark "Are you sure it is a good idea to release this?"
From my experience so far, the answer is absolutely. I waited a full year after submitting a detailed bugtraq posting, as well as reporting the vulnerability to a major affected vendor, and still nothing happened. Without at least a demo, it seems that people are either not inclined to believe your vulnerability is real, or not motivated to invest the effort in fixing it. In fact, even during a live demonstration, I had difficulty performing it in such a way that it was clear I was actually successfully exploiting live sites.
Yet when I announced I would be releasing a tool, just four days before my talk, a gmail announced an option-based "fix". I do not think this is a coincidence, and certain parties have indicated to me that it was not. To make matters worse, already the PR storm has gotten away from me, and the issue has somehow morphed into a gmail-specific flaw, that once fixed by gmail, will likely be forgotten. Especially if there was only a demo to go on.
In fact, even many of my friends who are developers for other sites were not immediately motivated to fix the issue, because "what are the odds that someone will target this site to steal its cookies?" This tells me that not only do people not really understand the risks involved, but they also don't fully understand the attack vector even after explanation (since an exploit can be fully automated to attack arbitrary sites).
To add insult to injury, many sites on the Internet handle extremely sensitive personal data, but do not support SSL at all. Despite my seemingly incessant targeting of them, Google deserves credit for being the only major email provider to support SSL past the login page. SSL may be expensive, but it certainly should be a market differentiator, and with the investment, it certainly should be done properly. Without a valid threat and the associated publicity storm to encourage people to choose secure, properly implemented, SSL-enabled services over insecure ones, the market is not going to function properly, and important sites will continue to be insecure, perhaps not even providing SSL at all.
Finally, to my surprise, a few affected sites (including Google) actually requested a copy of the tool to verify their fixes were secure against these attacks. To me, this underscores the importance of releasing the tool, given the number of potentially affected sites.
So with all these factors in play, it seemed that the only way to fully communicate exactly how this vulnerability works and how dangerous unimplemented or improperly implemented SSL can be was for me to demonstrate the issue and provide full exploit code for it.
At the same time, just because I don't release code does not make the Internet any more secure, or make you any safer. In fact, just 2 days after my talk, an independent (yet less functional) reimplementation has already surfaced. Being quiet or not disclosing full details would only promote ignorance and a false sense of security among the general populace, but it still provides full understanding to the adversary, who is considerably more knowledgeable and able to recreate this code in a matter of days. Remaining silent also gives developers an excuse not to implement what is at the end of the day a very simple fix. I pity them, because I don't like being forced to do work or spend money either, but those are the breaks.
However, releasing the tool is not without its costs, and it is not a decision I made lightly. It is likely that releasing the tool will make my travel to countries like the UK, Germany and elsewhere more risky. Of course, these laws are devastating to security for all the reasons listed above, and are worth vocally protesting and opposing, but that still doesn't prevent a potentially politically motivated or just random enforcement of these laws from really ruining a vacation.
But I'm done being chilled, so I will not let legislative idiocy be a deterrent. I have always disagreed with any law that limits the distribution of code. I firmly believe that human readable program code very much qualifies as speech, and should be protected at all costs, even if it is exploit code or instruction that causes people in power some inconvenience. Without freedom of speech, truth and justice become relative concepts, fungible to such nebulous qualifications as the "stability of society", and which "truth" is "best for the greatest number of people", and we have plainly witnessed the outcome of such utilitarian concepts when they are liberally applied in states like China.