Software Vulnerability Disclosure: The Chilling Effect

How the Web makes creating software vulnerabilities easier, disclosing them more difficult and discovering them possibly illegal

1 2 3 Page 2
Page 2 of 3

Recently, economist Arora conducted several detailed economic and mathematical studies on disclosure, one of which seemed to prove that vendors patch software faster when bugs are reported through this system. For packaged software, responsible disclosure works.

From Buffer Overflows to Cross-Site Scripting

Three vulnerabilities that followed the responsible disclosure process recently are CVE-2006-3873, a buffer overflow in an Internet Explorer DLL file; CVE-2006-3961, a buffer overflow in an Active X control in a McAfee product; and CVE-2006-4565, a buffer overflow in the Firefox browser and Thunderbird e-mail program. It's not surprising that all three are buffer overflows. With shrink-wrapped software, buffer overflows have been for years the predominant vulnerability discovered and exploited.

But shrink-wrapped, distributable software, while still proliferating and still being exploited, is a less desirable target for exploiters than it once was. This isn't because shrink-wrapped software is harder to hack than it used to be—the number of buffer overflows discovered has remained steady for half a decade, according to the CVE (see chart on Page 21). Rather, it's because websites have even more vulnerabilities than packaged software, and Web vulnerabilities are as easy to discover and hack and, more and more, that's where hacking is most profitable. In military parlance, webpages provide a target-rich environment.

The speed with which Web vulnerabilities have risen to dominate the vulnerability discussion is startling. Between 2004 and 2006, buffer overflows dropped from the number-one reported class of vulnerability to number four. Counter to that, Web vulnerabilities shot past buffer overflows to take the top three spots. The number-one reported vulnerability, cross-site scripting (XSS) comprised one in five of all CVE-reported bugs in 2006.

To understand XSS is to understand why, from a technical perspective, it will be so hard to apply responsible disclosure principles to Web vulnerabilities.

Cross-site scripting (which is something of a misnomer) uses vulnerabilities in webpages to insert code, or scripts. The code is injected into the vulnerable site unwittingly by the victim, who usually clicks on a link that has HTML and JavaScript embedded in it. (Another variety, less common and more serious, doesn't require a click). The link might promise a free iPod or simply seem so innocuous, a link to a news story, say, that the user won't deem it dangerous. Once clicked, though, the embedded exploit executes on the targeted website's server. The scripts will usually have a malicious intent—from simply defacing the website to stealing cookies or passwords, or redirecting the user to a fake webpage embedded in a legitimate site, a high-end phishing scheme that affected PayPal last year. A buffer overflow targets an application. But XSS is, as researcher Jeremiah Grossman (founder of WhiteHat Security) puts it, "an attack on the user, not the system." It requires the user to visit the vulnerable site and participate in executing the code.

This is reason number one it's harder to disclose Web vulnerabilities. What exactly is the vulnerability in this XSS scenario? Is it the design of the page? Yes, in part. But often, it's also the social engineering performed on the user and his browser. A hacker who calls himself RSnake and who's regarded in the research community as an expert on XSS goes even further, saying, "[XSS is] a gateway. All it means is I can pull some code in from somewhere." In some sense it is like the door to a house. Is a door a vulnerability? Or is it when it's left unlocked that it becomes a vulnerability? When do you report a door as a weakness—when it's just there, when it's left unlocked, or when someone illegally or unwittingly walks through it? In the same way, it's possible to argue that careless users are as much to blame for XSS as software flaws. For the moment, let's treat XSS, the ability to inject code, as a technical vulnerability.

Problem number two with disclosure of XSS is its prevalence. Grossman, who founded his own research company, White Hat, claims XSS vulnerabilities can be found in 70 percent of websites. RSnake goes further. "I know Jeremiah says seven of 10. I'd say there's only one in 30 I come across where the XSS isn't totally obvious. I don't know of a company I couldn't break into [using XSS]."

If you apply Grossman's number to a recent Netcraft survey, which estimated that there are close to 100 million websites, you've got 70 million sites with XSS vulnerabilities. Repairing them one-off, two-off, 200,000-off is spitting in the proverbial ocean. Even if you've disclosed, you've done very little to reduce the overall risk of exploit. "Logistically, there's no way to disclose this stuff to all the interested parties," Grossman says. "I used to think it was my moral professional duty to report every vulnerability, but it would take up my whole day."

What's more, new XSS vulnerabilities are created all the time, first because many programming languages have been made so easy to use that amateurs can rapidly build highly insecure webpages. And second because, in those slick, dynamic pages commonly marketed as "Web 2.0," code is both highly customized and constantly changing, says Wysopal, who is now CTO of VeriCode. "For example, look at IIS [Microsoft's shrink-wrapped Web server software]," he says. "For about two years people were hammering on that and disclosing all kinds of flaws. But in the last couple of years, there have been almost no new vulnerabilities with IIS. It went from being a dog to one of the highest security products out there. But it was one code base and lots of give-and-take between researchers and the vendor, over and over.

"On the Web, you don't have that give and take," he says. You can't continually improve a webpage's code because "Web code is highly customized. You won't see the same code on two different banking sites, and the code changes all the time."

That means, in the case of Web vulnerabilities, says Christey, "every input and every button you can press is a potential place to attack. And because so much data is moving you can lose complete control. Many of these vulnerabilities work by mixing code where you expect to mix it. It creates flexibility but it also creates an opportunity for hacking."

There are in fact so many variables in a Web session—how the site is configured and updated, how the browser is visiting the site configured to interact with the site—that vulnerabilities to some extent become a function of complexity. They may affect some subset of users—people who use one browser over another, say. When it's difficult to even recreate the set of variables that comprise a vulnerability, it's hard to responsibly disclose that vulnerability.

"In some ways," RSnake says, "there is no hope. I'm not comfortable telling companies that I know how to protect them from this."

A WAKE-UP CALL for websites

Around breakfast one day late last August, RSnake started a thread on his discussion board, Sla.ckers.org, a site frequented by hackers and researchers looking for interesting new exploits and trends in Web vulnerabilities. RSnake's first post was titled "So it begins." All that followed were two links, www.alexa.com and www.altavista.com, and a short note: "These have been out there for a while but are still unfixed." Clicking on the links exploited XSS vulnerabilities with a reasonably harmless, proof-of-concept script. RSnake had disclosed vulnerabilities.

He did this because he felt the research community and, more to the point, the public at large, neither understood nor respected the seriousness and prevalence of XSS. It was time, he says, to do some guerilla vulnerability disclosure. "I want them to understand this isn't Joe Shmoe finding a little hole and building a phishing site," RSnake says. "This is one of the pieces of the puzzle that could be used as a nasty tool."

If that first post didn't serve as a wake-up call, what followed it should. Hundreds of XSS vulnerabilities were disclosed by the regular klatch of hackers at the site. Most exploited well-known, highly trafficked sites. Usually the posts included a link that included a proof-of-concept exploit. An XSS hole in www.gm.com, for example, simply delivered a pop-up dialog box with an exclamation mark in the box. By early October, anonymous lurkers were contributing long lists of XSS-vulnerable sites. In one set of these, exploit links connected to a defaced page with Sylvester Stallone's picture on it and the message "This page has been hacked! You got Stallown3d!1" The sites this hacker contributed included the websites of USA Today, The New York Times, The Boston Globe, ABC, CBS, Warner Bros., Petco, Nike, and Linens 'n Things. "What can I say?" RSnake wrote. "We have some kick-ass lurkers here."

Some of the XSS holes were closed up shortly after appearing on the site. Others remain vulnerable. At least one person tried to get the discussion board shut down, RSnake says, and a couple of others "didn't react in a way that I thought was responsible." Contacts from a few of the victim sites—Google and Mozilla, among others—called to tell RSnake they'd fixed the problem and "to say thanks through gritted teeth." Most haven't contacted him, and he suspects most know about neither the discussion thread nor their XSS vulnerabilities.

By early November last year, the number of vulnerable sites posted reached 1,000, many discovered by RSnake himself. His signature on his posts reads "RSnake—Gotta love it." It connotes an aloofness that permeates the discussion thread, as if finding XSS vulnerabilities were too easy. It's fun but hardly professionally interesting, like Tom Brady playing flag football.

Clearly, this is not responsible disclosure by the standards shrink-wrapped software has come to be judged, but RSnake doesn't think responsible disclosure, even if it were somehow developed for Web vulnerabilities (and we've already seen how hard that will be, technically), can work. For one, he says, he'd be spending all day filling out vulnerability reports. But more to the point, "If I went out of my way to tell them they're vulnerable, they may or may not fix it, and, most importantly, the public doesn't get that this is a big problem."

Discovery Is (Not?) a Crime

RSnake is not alone in his skepticism over proper channels being used for something like XSS vulnerabilities. Wysopal himself says that responsible disclosure guidelines, ones he helped develop, "don't apply at all with Web vulnerabilities." Implicit in his and Christey's process was the idea that the person disclosing the vulnerabilities was entitled to discover them in the first place, that the software was theirs to inspect. (Even on your own software, the end user license agreement—EULA—and the Digital Millennium Copyright Act—DMCA—limit what you can do with/to it). The seemingly endless string of websites RSnake and the small band of hackers had outed were not theirs to audit.

Disclosing the XSS vulnerabilities on those websites was implicitly confessing to having discovered that vulnerability. Posting the exploit code—no matter how innocuous—was definitive proof of discovery. That, it turns out, might be illegal.

No one knows for sure yet if it is, but how the law develops will determine whether vulnerability research will get back on track or devolve into the unorganized bazaar that it once was and that RSnake's discussion board hints it could be.

The case law in this space is sparse, but one of the few recent cases that address vulnerability discovery is not encouraging. A man named Eric McCarty, after allegedly being denied admission to the University of Southern California, hacked the online admission system, copied seven records from the database and mailed the information under a pseudonym to a security news website. The website notified the university and subsequently published information about the vulnerability. McCarty made little attempt to cover his tracks and even blogged about the hack. Soon enough, he was charged with a crime. The case is somewhat addled, says Jennifer Granick, a prominent lawyer in the vulnerability disclosure field and executive director at Stanford's Center for Internet and Society. "The prosecutor argued that it's because he copied the data and sent it to an unauthorized person that he's being charged," says Granick, "but copying data isn't illegal. So you're prosecuting for unauthorized testing of the system"—what any Web vulnerability discoverer is doing—"but you're motivated by what they did with the information. It's kind of scary."

Two cases in a similar vein preceded McCarty's. One was acquitted in less than half an hour, Granick says; in the other, prosecutors managed to convict the hacker, but, in a strange twist, they dropped the conviction on appeal (Granick represented the defendant on the appeal). In the USC case, though, McCarty pleaded guilty to unauthorized access. Granick calls this "terrible and detrimental."

"Law says you can't access computers without permission," she explains. "Permission on a website is implied. So far, we've relied on that. The Internet couldn't work if you had to get permission every time you wanted to access something. But what if you're using a website in a way that's possible but that the owner didn't intend? The question is whether the law prohibits you from exploring all the ways a website works," including through vulnerabilities.

1 2 3 Page 2
Page 2 of 3
SUBSCRIBE! Get the best of CSO delivered to your email inbox.