- Related Stories
Google Gears churns toward MicrosoftMay 31, 2007
Mozilla mulls Windows cursor flaw fix of its ownApril 4, 2007
DIY boarding pass site gets shut downOctober 30, 2006
- Related Blogs
Popular add-ons to Firefox are the latest criminal attack vector
May 30, 2007
(continued from previous page)
There's also some risk involved. There's the case of Mike Lynn, who discovered some stuff a few years ago with Cisco, there were two researchers who discovered some vulnerabilities in the BlackBoard academic software, and there were some researchers last year who discovered some stuff with the Apple wireless device drivers. When researchers decide to go public themselves and they give advance notification to the vendors they put themselves at risk because, in many cases, trigger-happy companies' first response is to sue the researcher in an attempt to silence the researcher.
Whenever you follow the responsible disclosure route, you're always taking a risk because the company knows your name and they can sic lawyers on you. So in my case I felt confident because I was going to be in Europe, beyond the reach of a trivial lawsuit, but there's always that risk. And if you're doing something for Apple, which has made a name for itself by suing researchers, then more than likely, if you're going to go the responsible disclosure route you're going to at least do it anonymously, unfortunately.
Companies often claim that reverse engineering violates the DMCA, right?
They use the DMCA as a means to an end. Essentially what they're trying to do is silence the researcher, and the DMCA is the tool of choice. If the DMCA didn't exist, they'd cite some other rule, maybe the Computer Fraud and Abuse Act or something else. The DMCA basically says you can have an encryption algorithm and no matter how weak it is, if it's protecting anything that's copyrighted, then anyone who reverse-engineers it is in theory breaking the law. The codes that come in cereal boxes in theory could come under the DMCA. We have to recognize that it's there, but in terms of respect, I don't think that law gets much credit in the industry.
Do you think the path you took to disclosing this Firefox extension vulnerability works? Would you go this route again?
It was definitely far more work for me to coordinate the vulnerability disclosure than to tell CERT or to sell it on the open market. The problem for me was that Google, especially, stonewalled me. I sent over five or six e-mails to them, and for 30 days I heard nothing back from them. It's really frustrating for the researcher because you're trying to do the right thing, and all you want to hear is, "We're working on it, we'll get back to you soon." You want to have some kind of heartbeat so that you know they're alive and they're working on it. And you don't want to feel that you're just being stonewalled.
So it's really frustrating when the companies just do not respond to your e-mails at all. It gives you food for thought, and it disincentivizes you to go to them the next time when you know for a fact that iDefense will return your e-mails and will actually send you a check in the mail, too.
I'm at the beginning of a Ph.D. in computer security, so there will be other vulnerabilities down the road. If this were a vulnerability with Apple, I wouldn't have taken the chance because I'm almost certain Apple would have sued me. Google has a very good reputation in the security community for responding to things. But up until now, most those have been issues that were made public, and Google scrambled to fix them in a day or two. There isn't too much information out there on Google's response to responsible disclosure and, so, yeah, this experience has been eye-opening.
Some vendors didn't respond.
There is another responsible disclosure policy out there that's quite respected by researchers--it's called the RFP policy. And that stipulates that the vendors should communicate with the security researcher every five days by e-mail, and failure to do so will result in immediate publication. Now I didn't want to go down that route because I thought it was a little bit harsh, but next time around, when I send the initial e-mail disclosure e-mail, I think I'm going to say this is the policy I'm following--if I don't hear from you every five days, I will go public.
This is my first time divulging a vulnerability. I didn't really know what I was doing, so I had to learn it on the job. I think next time around I'm going to be much clearer with what the rules are and what the consequences are for lack of communications, but I really feel like if the companies want researchers to come to them and to not publish it on day one, or not sell it on the open market, they need to make it as easy as possible and they need to incentivize researchers. I'm not talking about giving away T-shirts here. Being reasonable and responding to our e-mails is a bare minimum, given that we are doing them a service, a free service in many cases.
It's been two days since you went public. Have you since heard from any of the vendors?
I have. Some have come out of the woodwork. Del.icio.us, a part of Yahoo, left comments on my blog and several other journalists' blogs stating that they actually fixed the issues before I went public. Somehow the news filtered through the Yahoo security team and the Del.icio.us guys patched things and got it out on time, so they were actually not vulnerable the day I went public.
Google tried to fix things. They patched some of their systems, but they're still exposed. As of 1 a.m. last night they didn't fix everything, so users are still vulnerable, including the new Google Gears extension, which I guess is getting a lot of publicity. The entire Google family of extensions is still vulnerable. Yahoo e-mailed me today (Friday, June 1) and told me they're expecting to have a fix out at some point in the future, but they're scrambling to find enough machines to host the updates. The reason being that when you shift from a regular HTTP to an SSL-enabled Web server--think about 2 to 3 million customers querying it every day--that's a lot more CPU that's required. So if they had a hundred machines serving up those updates before, they're now going to need two or three hundred machines. So this an actual bump in CPU power that's required. I believe Yahoo is now scrambling to find enough machines for that. I haven't heard back from any other vendors, though.
The extra CPU required to patch this--could that be why some vendors haven't?
Most of the companies that we're looking at here are multimillion-dollar firms. I'm not too concerned that AOL or Apple or Ask.com are not going to be able to pay for a few extra machines. Those firms that cannot afford that, the Mozilla.org extension servers are available to them whenever they want to use them. (The multimillion-dollar firms have) gotten themselves into this mess because they wanted users to download stuff directly from them. They wanted to control the eyeballs 100 percent of the way, they wanted to be able to monitor downloads and everything else, so now they are paying the consequences for it. Should they decide it is too much trouble for them, they can always go back to using the Mozilla servers.
The only aspect that's a little bit complicated is that there are terms and conditions with having your extensions hosted on Mozilla, and you must not disable the update prompting...If you have an extension hosted on the Mozilla servers, users must be prompted when the extension is updated. Google in particular disabled the extension update notification so that the extension would download secretly without the user ever being told. That kind of behavior will get you thrown off the Mozilla servers.
Any reason why Google would do that?
There are lots of reasons why. People are more likely to update when they don't have to choose to do so. From a security standpoint it's probably a good idea to have people running the latest code, but if the update process itself is vulnerable then that puts people in a lot of danger. Someone made a management decision there and in this specific case it came out wrong.