…I felt some obligation to treat them with respect. So I chose to contact the vendors myself instead of giving information to CERT or selling it on the open market. For me, that meant there was a lot more work. I had to do the co-ordination myself.
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 set 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 recognise that it's there but, in terms of respect, I don't think that law gets much credit in the industry.
If this were a vulnerability with Apple, I wouldn't have taken the chance because I'm almost certain Apple would have sued me
Christopher Soghoian, security researcher
Do you think the path you took to disclosing this Firefox extension vulnerability works? Would you take this route again?
It was definitely far more work for me to co-ordinate 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 emails 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 emails at all. It gives you food for thought and it disincentivises you to go to them the next time when you know for a fact that iDefense will return your emails and will actually send you a cheque in the mail, too.
I'm at the beginning of a PhD 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 [of] 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 email, 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 disclosure email, 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 incentivise researchers. I'm not talking about giving away T-shirts here. Being reasonable and responding to our emails is a bare minimum, given that we are doing them a service, a free service in many cases.
[The multi-million-dollar firms have] gotten themselves into this mess because they wanted users to download stuff directly from them
Christopher Soghoian, security researcher
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 am 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 emailed me today [Friday, 1 June] 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 a SSL-enabled web server — think about two to three million customers querying it every day — that's a lot more CPU that's required. So, if they had 100 machines serving up those updates before, they're now going to need 200 or 300 machines. So [there's] 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 multi-million-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 multi-million-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 behaviour 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.
