Releasing Firesheep: Right Intention, Wrong Action

Eric Butler released Firesheep, a Firefox extension that makes stealing others' Web sessions trivial. Firesheep steals the cookies associated with a user session and then uses the cookie to let you, the attacker,  start a new HTTP session impersonating the victim. It's trivial. All you need is to be able to sniff the traffic over the air or off the wire. I spent all of 3 minutes downloading and installing Firesheep before I hijacked my wife's Facebook session. It also works on other common social media sites such as Twitter and Yelp. You can also add new sites that use session cookies. 

Butler said he released Firesheep to shine a light on a prevalent problem. I agree that session stealing, aka sidejacking, should be addressed. But releasing a tool my grandmother could use is irresponsible.

I have long been an advocate for full disclosure. Software vendors have a responsibility to write and release secure code. Yet common, and fixable, problems persist, including buffer overflows or the failure to scrub input. Unfortunately, software vendors tend to put revenue above user security and won't actually fix problems in a timely manner unless there is a direct threat to their revenue. I won't get into the history, but there are plenty of examples from the last ten years. Full disclosure is the stick that makes recalcitrant vendors act responsibly.

Responsible disclosure is the carrot. The idea behind responsible disclosure is to give the vendor time to fix a problem before the problem is announced. No one expects software to be defect-free and squashing bugs takes time. Responsible disclosure is effective because everyone gets to be a good guy: Vendors get PR credit for fixing the problem. Researchers get props for their work. Most importantly, customers get a more secure product. But the game changes when one party or the other fails to act responsibly. (And no,  I don't have a definition of "timely" or "responsible" and I don't want to go there--at least not in this post.)

Session cookies should be protected, particularly as social media sites get more popular. Web sites use session cookies because keeping users logged in is easier than re-entering credentials, but session cookies are bad for user security because sidejacking is relatively simple. All you needed was a protocol analyzer, access to the media. Knowledge of a particular web applications cookie usage (they are all different). The ability to copy  the session cookie, or relevant bytes of a session cookie, into a new HTTP session. Ok, sidejacking wasn't trivial for your average bear, but it was possible.Firesheep makes it so easy, even a caveman could do it. And that means many users--perhaps even the the majority of web users--are totally helpless to protect against the attack. Tech Crunch points  to a potential workaround using another Firefox extension, Force-TLS which tries to force the browser to use TLS, but how many users will actually use it? For that matter, how many sites will Force-TLS be useful on?

The potential for damage is probably as big as the DNS bug that Dan Kaminsky found  in 2008. Kaminsky worked with DNS server vendors and providers to figure out a workable solution, to get the solution deployed, and develop software patches.  This gave everyone time to address the problem before it had a chance to spread.

Granted, the situation with session cookies is different. The problem is already known and being actively ignored by Web sites that don't using SSL/TLS to encrypt Web sessions. I understand why Bulter released the tool. I get frustrated by Web sites or companies that fail to address security issues unless they are forced to. But I think it was the wrong move. Let's remember that there is a victim here. I suspect there will be an increase in sidejacking but that doesn't mean web sites will do anything about it. In this case, I don't think any real good will come from this full disclosure.