Why Full Disclosure?

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.

How do I put this...

No one believes in the Bill of Rights more than I do... no one. However, "free speech" doesn't mean you have the right to yell "Fire!" in a crowded movie theater (or wherever--yeah, that old chestnut). You should simply have the common sense to not do it. In this case, though, you're pretty much lighting the match.

Re: How do I put this

Apparently then, you would still forbid the sale of matches in stores because someone might light a fire and then yell "fire" in a theater?

What would you suggest I do with requests by people to obtain the tool to test their sites? Who gets the tool? Who doesn't? What about the other independent reimplementations of the attack? Do I deny these requests and hope no one figures out how to code their own exploits, and allow people a false sense of security because the only other publicly available exploits are less automated and complete?

I'll answer for you, because I'm guessing you're not too familiar with computer security: The correct approach is to encourage people to implement the fix and verify it works. This is how things get secure: by testing them and fixing them when they break, and doing this as publicly as possible so it can be audited and reviewed by others. Putting our heads in the sand and hoping that whatever improper protections that are put in place will somehow manage to work, even when they clearly don't is not only childish, it is outright dangerous.

Re: Re: How do I put this

There's a big difference between providing a useful tool to responsible, security-conscious people (sysadmins, for instance) and simply dropping it into public hands where there is no doubt whatsoever that it will be used maliciously.

I certainly don't fault you for your goal, only your methodology. Publicize there's a flaw... sure. "Shame" sites into fixing their flaws... absolutely (if that's even possible). Distributing the tool to anyone and everyone... now that's dangerous. However, it's your conscience, not mine. The question is, will your actions make the Internet safer? or more unsafe? Whose head is it that's really in the sand here?

By the way, I used to be the chief security officer for a medium-sized university; but I'm retired now, so I don't have to worry about that kind of stuff any moreso than any other user of the Internet.

Re: How do I put this

Again, given that the exploit is so easy to implement (literally like 5-6 days, or 2-3 weekends of work) I don't think that any argument can be made wrt to its ultimate release.

However, I do agree that in this short time window we have before its inevitable widespread propagation that it is important to get it to people who will test their sites first. Hence my most recent blog post on the subject. After I begin to give it to these people, even if it was difficult to implement (which I assure you, it is not), it will still leak. If there's one thing the Internet does best, it's distribute information. Especially information people try to imperfectly control.

After that point, if sites refuse to secure themselves, well, its up to their users to migrate to their competitors who will.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
  ___   _   _   _   _  __  __  _   _ 
|_ _| | | | | | | | | \ \/ / | | | |
| | | |_| | | | | | \ / | | | |
| | | _ | | |_| | / \ | |_| |
|___| |_| |_| \___/ /_/\_\ \___/
Enter the code depicted in ASCII art style.