shouting loudly

Having studied the DRM fight for a few years now, I’m starting to become fascinated by the politics of security vulnerabilities in general.

For those of us who came to this question via the study of DRM politics, Ed Felten is perhaps the poster boy for the politics of security vulnerabilities. The professor of computer science and public affairs at Princeton was once threatened with legal action by the RIAA because his research team hacked the Secure Digital Music Initiative watermarking system and was about to discuss the hack at an academic conference.

Last year, Felten helped users cope with the security vulnerabilities that some Sony music CDs created on the computers into which they were inserted. Lately, he’s been telling anyone who will listen, from readers of his blog to members of the House Administration Committee, that Diebold e-voting machines are remarkably insecure.

At each step, he has told people who didn’t want to hear it that the digital lock they’ve devised is not half as secure as their PR department would have you believe. The fact that Diebold felt compelled to respond (pdf) illustrates that he has a substantial audience for such discoveries.

Of course, Felten is not alone, but he may be the whitest hat in the crowd. (The RIAA backed off, in part, b/c they knew they would endanger the political viability of their DMCA suit-fest.) Other people who research digital security have several means to spread the word about vulnerabilities. You can contact the CERT Coordination Center (CERT/CC), which will notify companies of vulnerabilities, help coordinate the response, and update the network user and service provider community of the status of the problem.

Until the alert and/or patch comes out, this is all pretty behind-the-scenes stuff and, by now, it’s become pretty routine. But every once in awhile, somebody violates protocol, either publicly discussing the flaw pre-patch or credibly dangling an exploit in front of security researchers without revealing the tricks so that they can patch it. Both have been in the news lately.

The now-famous Apple wifi vulnerability, performed by SecureWorks researcher David Maynor in this video, was an instance of the latter. It quickly devolved into name calling. Initially, Apple claimed that the two researchers, Maynor and Jon “Johnny Cache” Ellch, had failed to share any code demonstrating an exploit. Later, SecureWorks said:

SecureWorks and Apple are working together in conjunction with the CERT Coordination Center on any reported security issues. We will not make any additional public statements regarding work underway until both companies agree, along with CERT/CC, that it is appropriate.

Apple also stated that they are working with SecureWorks.

Some accused Maynor and Ellch of being irresponsible (not going directly to CERT), but the accusation by Apple and others that really angered them was that it was a cold fusion discovery–that is, they fabricated the whole thing. (With a little bit of effort, a great many people could perform what would look like the same hack without actually finding new vulnerabilities.)
Ellch gave a presentation on Saturday at ToorCon that defended their hacker honor as honestly having discovered a real vulnerability. SecureWorks pulled Maynor from the talk, during which the two were to share the code that enabled the exploit. Prevented from sharing the exploit (it sounds like his co-researcher had his arm twisted), Ellch’s speech was a self-described rant that left many to wonder what exactly was going on behind closed doors. All we know for sure is that this is definitely not the routine method for fixing vulnerabilities.

In contrast, nobody at ToorCon was doubting this Firefox exploit, also delivered on Saturday, by Mischa Spiegelmock and Andrew Wbeelsoi. (In case you care, it exploits Firefox’s implementation of JavaScript, which Spiegelmock calls “a complete mess” that is “impossible to fix.”) He put it on the screen for all to see–without having given Mozilla any lead time to begin to develop a patch.

Mozilla security chief Window Snyder (now THAT’S a name for an IT pro!) was not amused. Here is CNet’s reporting:

“It looks like they had enough information in their slide for an attacker to reproduce it,” [Snyder] said. “I think it is unfortunate because it puts users at risk, but that seems to be their goal.”

At the same time, the presentation probably gives Mozilla enough data to fix the apparent flaw, Snyder said. However, because the possible flaw appears to be in the part of the browser that deals with JavaScript, addressing it might be tougher than the average patch, she added. “If it is in the JavaScript virtual machine, it is not going to be a quick fix,” Snyder said.

Again, this deliberate release of a zero-day exploit is a clear violation of the heads-up-to-CERT protocol. The authors also claim to know of around 30 more unpatched Firefox flaws; they’re keeping those to themselves.

If this blog had a big audience, undoubtedly some of you would be insisting that zero-day exploits must be made illegal–that security flaws must be disclosed only to certain kinds of entities. (I’m still waiting for the high-publicity “war on hacking.” All we need is a “digital 9/11,” and the same mentality that brought you the very successful wars on drugs and terrorism will kick in.)

If the brief history of the DMCA is any indicator, that’s the wrong attitude. Felten was reluctant to release details about the Sony rootkit because he was scared of DMCA-fueled legal trouble. Additionally, part of CERT’s success has been in pressuring private firms to develop more secure products. Without third-party pressure, they just won’t do it. Sure, CERT works now, but that model may fail in the future.

Additionally, open source models (an important part of the “freedom to tinker”) generally provide greater security than proprietary closed source models (the Windows model, complete with public begging that the software’s producers release patches more quickly). If anyone can see the code, anyone can find and fix vulnerabilities, and more will be found and squashed. But if tinkering with the code is forbidden–by closed-source publishing models, EULAs, and/or the law–then only two kinds of people will look for bugs: people who have an incentive to avoid embarrassment (the authors of said closed-source code) and people who have the intention to exploit them.

Despite the pain of hacker conferees occasionally publicizing zero-day vulnerabilities and/or taunting us with their still-secret exploits, I’d still prefer a policy of freedom of information, knowing that the Feltens of the world got our collective back, over a system that prevents computer science professors and other whitehats from investigating and fixing flaws.