Share
What makes up proper disclosure when it comes to security? What is Full Disclosure and how is it different or related to other mentioned types of disclosure? During a recent talk at the 25th annual CCC, researchers highlighted a flaw within SSL and pointed to a company owned by VeriSign. VeriSign feels slighted by this, as it claims it had no warning from the researchers before the talk was given.
VeriSign says they had no notice before the CCC talk on SSL issues. The CCC researchers disagree.(IMG: J.ANDERSON)
However, the researchers maintain that they informed VeriSign beforehand, following proper disclosure and giving VeriSign details on the talk a week before it took place.
Update 2:
Tim as posted a responce to the new information that was released by the CCC researchers. You can view that here.
"Based on this new post it appears that Alexander Sotirov and his companions did indeed ask an intermediary, Microsoft, to contact VeriSign. The timing of that contact diminished its ability to help us considerably. I don't know anybody at VeriSign who had information about when and where this presentation would take place."
Update:
Alex Sotirov, one of the presenters at the CCC where this story originates, emailed The Tech Herald with more information concerning the disclosure questions. From the looks of things, the perceived lack of notice is a direct result of a breakdown in communication within VeriSign.
“I just published all the details about the information we provided to VeriSign through Microsoft. They were made aware of our results a week before the presentation and we answered all questions they had,” Alex said in his email.
“I believe that Tim Callan's claims that VeriSign did not receive any useful information before the presentation are a result of a simple miscommunication between their technical people and their marketing department.”
The site where the logs are posted explains more. “Not only did we contact VeriSign before our presentation to let them know about our research, we also strongly advised them to stop using MD5 as soon as possible and were given a chance to review their mitigation plans.”
So VeriSign, or at least someone within VeriSign not only knew about the talk, but shared mitigation plans with the research team. This fact only lends more creditability to the theory that lack of communication caused this debate.
“Since we had already taken steps to ensure that the attack could not be easily repeated, notifying the affected certificate authorities before our presentation was not required in order to protect Internet users. A more important consideration was to ensure that we could present our work at the Chaos Computer Congress without interference,” wrote Alex, detailing the though process and reasoning behind the methods of notification.
“In the last year we have seen multiple cases in which companies have used legal threats in an attempt to silence security researchers and prevent the release of information that exposes their security failures..."
"Since the affected CAs did not have a significant track record of responding to public security vulnerabilities in their systems, we could not be confident that they wouldn't overreact and attempt to stop or delay our presentation through legal or other means. It was this feeling of uncertainty that led to our decision to avoid direct contact with them and to obtain Non-Disclosure Agreements from the browser vendors we contacted,” the report explains.
Yesterday, The Tech Herald sent out an e-mail to the team who presented the CCC talk, asking for the name of the VeriSign contact used when making the disclosure. We were told that Microsoft volunteered to act as a “trusted intermediary” and coordinate communication between the researchers and CAs.
According to late night e-mails to The Tech Herald from Alex and Arjen Lenstra, Microsoft was supposed to speak to VeriSign about the creation of a rogue CA and MD5 collision one week before the talk. (Full communication logs from Microsoft are found here.)
This notice to VeriSign from Microsoft, acting on behalf of the researchers, was only to deal with the new advancements to the previous research. The new advancements led to the creation of rogue certificates by a rogue CA that was entirely under the research team’s control.
As Arjen pointed out in one e-mail, the cryptographic community was previously aware of the issues (and VeriSign should've been aware of the problems way beforehand) with the use of MD5, predictable serial numbers, and validity periods that can be controlled by an attacker.
Case in point; take the following paragraph from the spring of 2007, when the previous research was published:
“Another problem is that the attacker must have sufficient control over the CA to predict all fields appearing before the public key, such as the serial number and the validity periods. It has frequently been suggested that this is an effective countermeasure against colliding certificate constructions in practice, but there is no consensus how hard it is to make accurate predictions. When this condition of sufficient control over the CA by the attacker is satisfied, colliding certificates based on chosen-prefix collisions are a bigger threat than those based on random collisions.”
The researchers have made it clear they have not attempted to hide the older research or accounts of their work. The research from 2007, for example, gained a lot of press and appeared in the Economist's technology Quarterly of Dec 2007 (mirror here).
The recent research, building on what was done in 2007, combined with the lack of changes from VeriSign with regard to the previously mentioned security issues, allowed them to not only create a rogue certificate, but a rogue CA. This is the central point of their attack and recent research.
However, because VeriSign maintains it had no notice before the talk, who was it that Microsoft spoke to? If it was not Tim Callan, then who was the contact? Where exactly did the ball drop?
When The Tech Herald last spoke to Tim Callan of VeriSign he said, "Some of the researchers are going on public forums saying ‘yes we did brief VeriSign’ and I don’t know why they are saying that because they just didn’t.”
“I think there’s an interesting side conversation that comes out of this, which is ‘what are the proper disclosure methods and what are not?’” added Callan. “I think we should all have that conversation, but let’s operate from correct facts when we have that conversation, and the facts are that VeriSign wasn’t briefed. Whether or not we should’ve been, I’ll let others worry about, but let’s be straight on the facts.”
It should be noted that, while there is a feeling of being slighted, VeriSign still maintains that the research was solid and that the talk given during the CCC was informative, complete, and accurate. Overall the researchers did great work, the company says.
The original story starts on page 2 of this article.
In the comments on Callan’s company blog, one of the researchers from the CCC talk disputed the claim that VeriSign was left in the cold.
“I am one of the researchers who presented this work at the CCC congress yesterday,” wrote Alexander Sotirov on December 31 of 2008.
“We did in fact notify VeriSign and all other affected certificate authorities through a trusted intermediary a week before the presentation. VeriSign was made aware that we've made improvements to the MD5 collision attack published in 2007 and that they need to stop using MD5 as soon as possible,” he said.
“In addition, we feel that the MD5 collision results from 2004-2007 served as a sufficient warning to any CA still using MD5. Your assertion "that VeriSign did not receive any of this information ahead of the actual presentation, rendering it impossible for us to begin work on mitigating this issue prior to this morning" is false and I'd like to see it corrected.”
With that said, in response to Alexander’s blog comments, Callan points out a possible problem with the intermediary:
“The trusted intermediary” was under a strict NDA with you and didn't feel it could reveal anything that was actually actionable or useful. Your NDA prevented the intermediary from telling us what would be announced, by whom, or when,” he said.
“You didn't invite us to view the presentation in person or on the webcast. Had VeriSign not discovered by other means that this presentation was coming, we may not have had the opportunity to hear what you had to say until after the fact. In addition to Microsoft and Mozilla [both who were under NDA], at a bare minimum you briefed The Washington Post, Wired Magazine, CNET, and IDG News Service prior to your announcement. You also briefed one or more active security bloggers,” he adds.
Callan goes on to point out the slide that thanks the legal team, which helped the researchers before their talk, and that it “gives an inaccurate impression to discuss 2004 as the starting date for mitigation of this vulnerability,” as VeriSign didn’t acquire RapidSSL until 2006 when it took over GeoTrust.
“The RapidSSL product line is something that VeriSign received in our acquisition of the company GeoTrust in September 2006,” Callan told The Tech Herald during his interview. “So that was the very first time we got to lift the hood, and begin the evaluation and investigation strategy.”
At the time, VeriSign felt that it was perfectly reasonable to stretch the removal of MD5 out over two years. This time frame changed, as once the information on the SSL attack made possible by MD5 collisions became public, allowing the creation of rogue CAs, the issue needed resolving now. Callan explained that it took his company about four hours to fix the issue (see the other related story: “SSL is not broken - the facts surrounding the CCC disclosure” for further details).
VeriSign was aware of the issues with MD5 when it purchased GeoTrust. However, it didn’t know all of the ways to exploit the issue. If it had known about the method detailed in the CCC talk, then it likely would have acted sooner, Callan explained.
The problem, and this is where the disclosure discussion comes into play, is that while it took VeriSign only four hours to fix the issue once it watched the CCC presentation, the company says it could have had the issue fixed long before the talk if only it had been made aware of the RapidSSL problems by the researchers.
According to some, the debate over Full Disclosure doesn’t start with security or technology, it starts with locksmithing. Locksmiths debated over whether to keep vulnerabilities within locking systems, to themselves, or release the details to the public. This gives a whole new spin to the modern locksmiths who hate the new trends where non-locksmithing hobbyists discover flaws and tell everyone, as well as teach others the art of lockpicking.
Full Disclosure, as most know, earned its limelight in the 1990s. Early on, the nature of disclosure was non-existent. It used to be that researchers would discover vulnerabilities and quietly alert vendors. The theory is that the vendors would then fix the vulnerabilities. That theory was often false, as fixes would come either in the next release or, in some cases, never at all. Then, the United States Computer Emergency Response Team, or CERT, was formed.
Researchers would send CERT vulnerability reports and, after verification, CERT would then alert the vendor. The vendor would issue a patch and CERT would release the details of the vulnerability and the link to the patch at the same time. The problem with that process is the lack of urgency. There is no reason for the vendor to patch because it knows CERT will not publish details until a patch is released. Later, CERT changed its policy, but that didn’t remove all of the issues that many complained about.
One issue for a few experts is the variation of disclosure. Sometimes there is a 30-day wait, other times there is a 45-day wait, and then there are the releases that see publication years after their initial discovery.
A compromise was duly formed: disclose the vulnerability to the vendor, and set a timeline for response. The researcher waits a few weeks for the vendor to follow-up. If no response from the vendor is seen, the researcher will alert them again to see if there is a patch. After about 30 days, if there is no response from the vendor, one final contact is attempted. If that fails, the researcher goes public. While that is fair to both the researcher and the vendor, the method is still attacked because each researcher has his or her own opinion on exactly what the terms of full disclosure mean and how long to wait.
Fast forward to the last two or three years, and the Full Disclosure debate is alive and well. This time however, there is money involved. ZDI, WSLabi, and other projects, including VeriSign’s own iDefense, aim at proper disclosure by offering to pay researchers for their work.
The adage that “researchers have to put food on the table” is the line often used to defend the work performed. There is solid evidence for this, as researchers spend large amounts of time doing their jobs, but the companies still argue that no one asked them to do this and, without proper notification, their actions of releasing their work to the public are still borderline criminal.
With money involved, there is more to it than etiquette, now you are playing with the household income of the very researchers who want to help. Most do the research on their own, and rightfully should see some compensation. This is why you have ZDI, iDefense, and WSLabi. Yet, there is another argument that says the money paid for the research is nowhere near the true value of the vulnerability.
There is also the harsh fact of lawsuits. Many researchers found the early disclosure processes frustrating. Several of them found themselves faced with threats of legal action if they released the details of any vulnerability by vendors they were attempting to help.
In 2005, proof of this was evident when Cisco created a huge PR mess when it sued researcher Mike Lynn and the Black Hat conference. The suit was to prevent Lynn from talking about flaws in Cisco’s IOS operating system.
Again, as recently as this past summer, three students from MIT were ordered by a federal court judge to cancel their scheduled presentation at Defcon, which centered on vulnerabilities in Boston's transit fare payment system.
"MBTA made the worst-possible decision by suing researchers for two reasons. First, the law suit disrupts all trust that has been built between researchers and industry and shatters progress we have recently made towards more responsible disclosure of vulnerabilities. Second, MBTA attracts attention to their weak system, while discouraging researchers to find solutions," said Karsten Nohl, a PhD and security researcher.
"When will industry stop fighting unreasonable law suits and start building secure systems? The research community is ready to help [build] more secure systems. But as long as hacking results in more attention for serious security issues than constructive work, we will keep hacking," he added.
Nohl himself knows all-too well the problems with disclosure because of his work presented in the past at the CCC. The Tech Herald spoke to Nohl on several occasions and covered his work on the Mifare Classic from NXP.
So would VeriSign have done the same, and prevented the CCC talk if it were in the loop? Would it have sued Alexander Sotirov, Marc Stevens, and Jacob Appelbaum to prevent the talk?
“I cannot imagine that we would have,” VeriSign’s Callan said. “We’ve never done anything that remotely smells of that kind of response. It’s not our policy. We’re also disappointed that all of those years of being on the right side of the line [with researchers] got us no credit at all with this set of researchers.”
Considering the recent climate, with researchers being sued for their work, you can see the justification behind Sotirov, Stevens, and Appelbaum obtaining legal advice and using NDA protection.
Callan said during the interview that he could see why they would need protection from companies who are known to go after researchers. Yet, he still maintained that even with examples of those “bad actors,” or the companies who present a good front to researchers then turn around and sue them for their work, VeriSign should have been given the benefit of the doubt with their existing track record.
“We can absolutely go back and look at examples where companies behaved in a way that we would not have wanted them to. At the same time, if we turn around and say ‘okay well based on that I’m going to penalize every company in the world and I’m not going to let anyone plug their security hole,’ well then why do we have white-hat security researchers at all? Aren’t they here to help us plug the holes before the bad guys get them?
“If we completely obviate the opportunity to share this information with the security providers, then we just sat ourselves back a long way. Now, we’re fortunate that we were able to respond so quickly to this... lets pretend that VeriSign had been unable to [respond so quickly] for one reason or another. Now all of the sudden the door is open for other people to sit down and look at what they presented say ‘okay can I do this myself, do I have enough information to do this myself?’”
Yet, the researchers held critical information back, which Callan said was good, “...but they also [revealed] a lot more than anybody would have thought of or worked through otherwise.”
Callan makes a point that the presentation at the CCC was well rounded, but most of the information served up on how they performed the attack, why they did it, etc., is a re-hashing of work done in 2004 and again in 2007. So while there was quite a bit of useful information presented, it was nothing that the security community wasn’t already aware of.
So would VeriSign have prevented the level of information presented? If it had allowed the researchers to do their talk at the CCC, would the company have filtered the level of information in the topic?
“I can’t imagine that we would’ve. It would have been completely out of character,” Callan commented. He did note that his bosses would have the power to do something different, but he didn’t see them doing that either.
The reasoning is that there needs to be trust, according to Callan.
“The researchers need to be able to trust in the fact that they can go to the vendors with this stuff and not have bad consequences. I’m sorry those [MIT researchers] who did. That was wrong, but wrong things happen in the world, and we don’t throw out the system because of it.”
Callan thinks that what happened with the lack of notification given to VeriSign about the issue should kick off a serious discussion over disclosure, and be used as a lesson.
“There has been well established etiquette that has worked for a long time, and a few companies have abused it. That’s bad, among other things, because it leads to abuse on the other end,” Callan said, noting that he feels that VeriSign was abused in this case.
Ultimately, Callan offered that the Full Disclosure issue is, “something that we need to look at.” While aware of the issue, he said, the events of the past week have made it clear to him that he was right in the middle of the argument all along, just that he didn’t know it at the time.
Partial, Public, and Private Disclosure are all pragmatic topics and interesting, Callan said, and before now he always assumed they would be solved pragmatically and in the moment.
“You would be there; you would look at the specifics of the attack, how it needed to be fixed, how it would need to be mitigated, and make a disclosure decision,” he explained.
Regarding the apparent abuse VeriSign suffered due to the lack of disclosure from the CCC researchers, Callan said: “It's fine, we’ll survive, we’re big boys. Still we need to ask ourselves is this the right way? What if it were a company that didn’t have the resources that VeriSign does and couldn’t respond so quickly? What if it was a smaller company or a resources constrained company? This is a dangerous road we are going down.”
Again, the team who presented at the CCC maintains that they communicated the issue with VeriSign beforehand, using Microsoft and including the existing knowledge of prior research which VeriSign was aware of.
The debate over disclosure, however, no matter if the information from the researchers proves beyond a doubt that they alerted VeriSign before the talk, will continue for a long time.
Interested in a more interactive TTH? Join our Facebook Group Want regular updates from The Tech Herald? Follow us on Twitter
Advertising
Comment on this Story