Derek E. Bambauer & Oliver Day, the Hacker?s Aegis

• Publication year: 2011

THE HACKER’S AEGIS

Derek E. Bambauer* Oliver Day**

ABSTRACT

Intellectual property (IP) law stifles critical research on software security vulnerabilities, placing computer users at risk. Researchers who discover flaws often face IP-based legal threats if they reveal findings to anyone other than the software vendor. This Article argues that the interplay between law and vulnerability data challenges existing scholarship on how intellectual property law should regulate information about improvements on protected works, and suggests weakening, not enhancing, IP protections where infringement is difficult to detect, lucrative, and creates significant negative externalities. It proposes a set of three reforms—“patches,” in software terms—to protect security research. Legal reform would create immunity from civil IP liability for researchers who follow “responsible disclosure” rules. Linguistic reform would seek to make the term hacker less threatening either by recapturing the term’s original meaning, or abandoning it. Finally, structural reform would ameliorate failures in the market for software vulnerability data by having a trusted third party act as a voluntary clearinghouse. The Article concludes by describing other areas, such as physical security, where it may be useful to reform how law coordinates IP improvements.

* Associate Professor of Law, Brooklyn Law School.

** Security Researcher, Akamai.

The authors thank Oded Burger, Jennifer Burgomaster, Jelena Kristic, Brad Reid, and Chris Vidiksis for expert research assistance. Thanks for helpful suggestions and discussion are owed to Miriam Baer, Fred Bloom, Adam Candeub, Mike Carroll, Jennifer Carter-Johnson, Ed Cheng, Jorge Contreras, Dino Dai Zovi, Erik Dykema, Robin Effron, Dave Fagundes, Shubha Ghosh, Jennifer Granick, Dan Guido, Lital Helman, Brian Lee, Dave Levine, Mike Madison, Jason Mazzone, Phil Malone, Liberty McAteer, Bill McGeveran, Maureen O’Rourke, Sean Pager, Gideon Parchomovsky, Zahr Said, Ted Sichelman, Jessica Silbey, Chris Soghoian, Alexander Sotirov, Marketa Trimble, Scott Velez, Jane Yakowitz, Fred Yen, Julie Cromer Young, the Intellectual Property Colloquium at Brooklyn Law School, and the participants in the Seventh Annual Works in Progress Intellectual Property conference. The authors gratefully acknowledge the Dean’s Summer Research Stipend Program and President Joan G. Wexler at Brooklyn Law School for financial support. The authors welcome comments at derek.bambauer@brooklaw.edu and oday@fas.harvard.edu.

INTRODUCTION: != BULLETPROOF 1053

1. THE SOFTWARE SECURITY ECOSYSTEM 1058

   1. The Stakes 1058

   2. Bug Hunters 1065

2. THE VENDOR’S ARSENAL 1068

   1. Copyright: Breaking the Censor’s Scissors 1068

   2. Patent 1069

   3. Trade Secret 1073

   4. Trademark 1079

   5. Digital Millennium Copyright Act (DMCA) 1080

3. CREATING THE AEGIS 1086

   1. Legal Reform 1086

      1. Tell the Vendor First 1089

      2. Do Not Sell the Bug 1090

      3. Test on Your Own System 1091

      4. Do Not Weaponize 1092

      5. Create a Trail 1092

   2. Form for Substance 1094

   3. Changing the Hacker Image 1097

   4. Freeing Markets 1100

   5. Challenges 1103

CONCLUSION 1106

INTRODUCTION: != BULLETPROOF1

Mike Lynn had done the impossible. He had found a way to crack open the operating system on Cisco internet routers, causing them to run his code.2 Routers were Cisco’s most important product—and the backbone of much of the internet—precisely because they had been legendarily immune to such attacks.3 Lynn, though, had discovered their Achilles’ heel. The routers’ vulnerability placed a wide swath of internet infrastructure at risk.

Lynn, an experienced security researcher with the firm Internet Security Systems (ISS), followed the protocol of “white hat” hackers, who probe for computer software and hardware flaws with the goal of discovering, not exploiting, them.4 He reported his findings to Cisco, which dutifully issued a patch to correct the bug.5 But Cisco—concerned with damaging the invincible image of its products—refused to draw particular attention to the patch, or to press customers to implement it.6 Lynn, worried by Cisco’s decision not to publicize the fix, prepared to give a presentation at the Black Hat hacker conference in Las Vegas that would detail the basic concepts of the bug, but would withhold information about how to exploit it.7

Cisco objected, fervently. Employing a range of legal theories from intellectual property law, the company convinced a federal judge to issue a restraining order preventing Lynn from giving his presentation.8 The company also forced conference organizers to rip the printed version of Lynn’s slides

1. In programming languages, != means “not equal to.” See Built-In Types—Python v2.7.1 Documentation, PYTHON STANDARD LIBR. § 5.3 tbl., http://docs.python.org/library/stdtypes.html#comparisons (last updated May 13, 2011).

2. Kim Zetter, Router Flaw Is a Ticking Bomb, WIRED (Aug. 1, 2005), http://www.wired.com/politics/

   security/news/2005/08/68365.

3. Robert Lemos, Cisco, ISS File Suit Against Rogue Researcher, SECURITYFOCUS (July 27, 2005), http:// www.securityfocus.com/news/11259.

4. By convention, black hat hackers discover bugs for financial gain or malicious reasons, and gray hat hackers behave either as white hats or black hats, depending on the circumstances. The tripartite division,

   borrowed from movie Westerns, corresponds roughly to good actors (white hats), bad ones (black hats), and those whose orientation varies (gray hats). See THOMAS WILHELM, PROFESSIONAL PENETRATION TESTING: CREATING AND OPERATING A FORMAL HACKING LAB 13–18 (2009).

5. Robert McMillan, Black Hat: ISS Researcher Quits Job to Detail Cisco Flaws, INFOWORLD (July 27,

   2005), http://www.infoworld.com/d/security-central/black-hat-iss-researcher-quits-job-detail-cisco-flaws-088.

6. See Zetter, supra note 2.

7. Jennifer Granick, An Insider’s View of ‘Ciscogate,’ WIRED (Aug. 5, 2005), http://www.wired.com/ science/discoveries/news/2005/08/68435.

8. Id.

   out of the conference materials, and to turn over CDs containing a copy of his slideshow.9

   
   

   This Article argues that conflicts such as the one between Lynn and Cisco are both increasingly common and socially harmful. Intellectual property (IP) law stifles the dissemination of critical research on software security vulnerabilities. We argue that IP law’s incentive effects are superfluous for these bugs, as security research is an exemplar of “peer production” as

   conceptualized by Yochai Benkler,10 Eric von Hippel,11 and Eric S.

   Raymond.12 Researchers hunt bugs for a variety of reasons: intellectual curiosity, ideology, reputation, and occasionally remuneration. For vulnerability research, IP law plays a suppressive rather than a generative function—it blocks or limits whether, and how, hackers share their findings.13 The suppressive effect is heightened by the fact that researchers can rarely, if

   ever, obtain IP law protection for their findings or insights. We argue that, much as researchers have hacked software to make it behave unexpectedly and thereby serve their purposes, software vendors have hacked IP law, using it for ends unrelated to its original purpose.

   
   

   Critically, IP law—like the software it protects—malfunctions here. It enables software firms to suppress information about flaws. It presses researchers to avoid legal risks from public disclosure and to gain financially by offering their findings on the black market rather than through legitimate channels. Software-vulnerability research challenges standard intellectual property scholarship on the regulation of information about improving a protected work or invention. Under current doctrine, someone who possesses information about how to improve a work or invention protected by IP has three options: bargain with the IP owner, seek an improvement patent, or infringe. Contemporary scholarship typically focuses on tuning patent and copyright law to generate optimal incentives and to coordinate improvements. Mark A. Lemley argues that it is unnecessary for inventors to capture the full

   
   

9. Bruce Schneier, Cisco Harasses Security Researcher, SCHNEIER ON SECURITY (July 29, 2005, 4:35 AM), http://www.schneier.com/blog/archives/2005/07/cisco_harasses.html.

10. Yochai Benkler, Coase’s Penguin, or, Linux and The Nature of the Firm, 112 YALE L.J. 369, 375

    (2002).

11. ERIC VON HIPPEL, DEMOCRATIZING INNOVATION 93–97 (2005) [hereinafter VON HIPPEL, DEMOCRATIZING INNOVATION]; ERIC VON HIPPEL, THE SOURCES OF INNOVATION 25–26 (1988) [hereinafter VON HIPPEL, THE SOURCES OF INNOVATION].

12. ERIC S. RAYMOND, THE CATHEDRAL AND THE BAZAAR 49–53 (Tim O’Reilly ed., rev. ed. 2001).

13. See generally Jonathan L. Zittrain, The Generative Internet, 119 HARV. L. REV. 1974 (2006) (describing how the internet’s architecture empowers users to generate innovation).

    social value of their advances, and that patent law should not set this internalization as a goal.14 Robert P. Merges and Richard R. Nelson analyze the incentive effects of various standards for setting the scope of a patent,15 as does Edmund W. Kitch.16 William M. Landes and Judge Richard A. Posner

    justify control over improvement information by IP owners as useful in reducing transaction costs.17 Michael A. Heller and Rebecca S. Eisenberg worry about the problem of holdout costs when multiple parties must bargain over improvements.18 Paul Goldstein assesses how copyright’s derivative works doctrine—particularly indifferent to economics—has created adverse effects on incentives to invest in copyrighted works.19 Current scholarly wisdom thus presses toward conferring control over improvement information to IP owners.

    
    

    This Article, in contrast, identifies software security research as a counterexample, where IP owners’ strong controls over improvement information are harmful. Security bugs are problematic for three reasons: infringement is (1) difficult to detect, (2) socially harmful due to negative externalities, and (3) lucrative. We argue that IP law should be alert to similar situations and that, counterintuitively, such circumstances require a diminution, not an increase, in IP protections. The Article goes on to...