Last February at Purdue University, a student taking "cs390s - Secure Computing" told his professor, Dr. Pascal Meunier, that a Web application he used for his physics class seemed to contain a serious vulnerability that made the app highly insecure. Such a discovery didn't surprise Meunier. "It's a secure computing class; naturally students want to discover vulnerabilities."
They probably want to impress their prof, too, who's a fixture in the vulnerability discovery and disclosure world. Dr. Meunier has created software that interfaces with vulnerability databases. He created ReAssure, a kind of vulnerability playground, a safe computing space to test exploits and perform what Meunier calls "logically destructive experiments." He sits on the board of editors for the Common Vulnerabilities and Exposures (CVE) service, the definitive dictionary of all confirmed software bugs. And he has managed the Vulnerabilities Database and Incident Response Database projects at Purdue's Center for Education and Research in Information and Assurance, or Cerias, an acronym pronounced like the adjective that means "no joke."
When the undergraduate approached Meunier, the professor sensed an educational opportunity and didn't hesitate to get involved. "We wanted to be good citizens and help prevent the exploit from being used," he says. In the context of vulnerable software, it would be the last time Meunier decided to be a good citizen. Meunier notified the authors of the physics department application that one of his students -- he didn't say which one -- had found a suspected flaw, "and their response was beautiful," says Meunier. They found, verified and fixed the bug right away, no questions asked.
But two months later, in April, the same physics department website was hacked. A detective approached Meunier, whose name was mentioned by the staff of the vulnerable website during questioning. The detective asked Meunier for the name of the student who had discovered the February vulnerability. The self-described "stubborn idealist" Meunier refused to name the student. He didn't believe it was in that student's character to hack the site and, furthermore, he didn't believe the vulnerability the student had discovered, which had been fixed, was even connected to the April hack.
The detective pushed him. Meunier recalls in his blog: "I was quickly threatened with the possibility of court orders, and the number of felony counts in the incident was brandished as justification for revealing the name of the student." Meunier's stomach knotted when some of his superiors sided with the detective and asked him to turn over the student. Meunier asked himself: "Was this worth losing my job? Was this worth the hassle of responding to court orders, subpoenas, and possibly having my computers (work and personal) seized?" Later, Meunier recast the downward spiral of emotions: "I was miffed, uneasy, disillusioned."
This is not good news for vulnerability research, the game of discovering and disclosing software flaws. True, discovery and disclosure always have been contentious topics in the information security ranks. For many years, no calculus existed for when and how to ethically disclose software vulnerabilities. Opinions varied on who should disclose them, too. Disclosure was a philosophical problem with no one answer but rather, schools of thought. Public shaming adherents advised security researchers, amateurs and professionals alike to go public with software flaws early and often and shame vendors into fixing their flawed code. Back-channel disciples believed in a strong but limited expert community of researchers working with vendors behind the scenes. Many others' disclosure tenets fell in between.
Still, in recent years, with shrink-wrapped software, the community has managed to develop a workable disclosure process. Standard operating procedures for discovering bugs have been accepted and guidelines for disclosing them to the vendor and the public have fallen into place, and they have seemed to work. Economists have even proved a correlation between what they call "responsible disclosure" and improved software security.
But then, right when security researchers were getting good at the disclosure game, the game changed. The most critical code moved to the Internet, where it was highly customized and constantly interacting with other highly customized code. And all this Web code changed often, too, sometimes daily. Vulnerabilities multiplied quickly. Exploits followed.
But researchers had no counterpart methodology for disclosing Web vulnerabilities that mirrored the system for vulnerability disclosure in off-the-shelf software. It's not even clear what constitutes a vulnerability on the Web. Finally, and most serious, legal experts can't yet say whether it's even legal to discover and disclose vulnerabilities on Web applications like the one that Meunier's student found.
To Meunier's relief, the student volunteered himself to the detective and was quickly cleared. But the effects of the episode are lasting. If it had come to it, Meunier says, he would have named the student to preserve his job, and he hated being put in that position. "Even if there turn out to be zero legal consequences" for disclosing Web vulnerabilities, Meunier says, "the inconvenience, the threat of being harassed is already a disincentive. So essentially now my research is restricted."
He ceased using disclosure as a teaching opportunity as well. Meunier wrote a five-point don't-ask-don't-tell plan he intended to give to cs390s students at the beginning of each semester. If they found a Web vulnerability, no matter how serious or threatening, Meunier wrote, he didn't want to hear about it. Furthermore, he said students should "delete any evidence you knew about this problem...go on with your life," although he later amended this advice to say students should report vulnerabilities to CERT/CC.
A gray pall, a palpable chilling effect has settled over the security research community. Many, like Meunier, have decided that the discovery and disclosure game is not worth the risk. The net effect of this is fewer people with good intentions willing to cast a necessary critical eye on software vulnerabilities. That leaves the malicious ones, unconcerned by the legal or social implications of what they do, as the dominant demographic still looking for Web vulnerabilities.