PC Security: Holey Software!

Bug Hunters

Despite the product evaluation that Microsoft and other vendors perform, security holes clearly pass through unnoticed. That is, until products hit the market and bug hunters take over with their own brand of rigorous testing.

Bug hunters find and publicize holes that vendors miss. They include a range of people: security researchers; system administrators; crackers (criminal hackers), who reverse-engineer a program specifically to exploit its flaws; and "white-hat" hackers, who find and publicize holes with no intent to wreak havoc on systems. Their aim is to force vendors to fix holes.

After finding a flaw, a bug hunter may or may not contact the vendor before posting the information to a list like BugTraq, where system administrators, security consultants, and journalists can read it. Vendors, of course, would prefer that vulnerabilities were never made public.

But hackers and security pros say that publication forces vendors to quickly fix problems they would otherwise ignore. It also lets users and system administrators take measures to protect themselves, thus decreasing the amount of time during which crackers who already know about a hole can silently exploit it. Even if a patch isn't available, users can disable a vulnerable feature until the patch is posted.

Rain Forest Puppy, a hacker who has written a disclosure policy that serves as an unofficial guideline for many bug hunters, says that even under threat of publication, vendors can be unresponsive to bug reports. Nonetheless, he advises bug hunters to give vendors five working days to respond to a report--whether that means promptly issuing a patch or stating the time needed to investigate a problem--before publicizing it. "If they don't acknowledge it in a week--if they're on vacation or whatever--then that's already a poor response," he says.

Full Disclosure

But not everyone thinks publicizing holes is a good idea, since crackers (some of whom are consultants and administrators, too) also read bug lists, looking for new holes to exploit. A month after a flaw in Microsoft's Information Internet Server (IIS) software was published, a cracker wrote the Code Red worm to exploit it.

Marcus Ranum, CTO of software vendor NFR Security, says that many PC users and administrators--for whatever reason--don't fix their systems even when a patch is available. Thus, publicity about holes makes their systems more vulnerable.

The problem is exacerbated if a bug report includes exploit code--programming code that demonstrates in practice what the report describes in theory. Bug finders sometimes post exploits to allow administrators to test their systems for holes or test a vendor's patch. And some programmers need the exploit to convince their bosses of the need to create a patch for customers. But once an exploit is published, it can also be used by crackers to break into systems.

Levy admits that disclosing holes is a double-edged sword. "Once you inform the good guys, you also inform the bad guys," he says. But he and Schneier say that disclosure has done more to help security than harm it--as evidenced by Microsoft's improved response to holes. And, Levy says, "Incredibly enough, until this year Apple didn't even have an e-mail address to report security problems. Now they do."

Disclosure, in the end, puts the onus on users and administrators to patch their systems. Hundreds of thousands of systems could have escaped the Code Red scourge in July had administrators fixed their systems a month earlier when Microsoft released a patch for the buffer overflow problem that the worm exploited. (See more coverage of full disclosure and software holes .)

Fighting Back

Though security problems might be endemic to software, Schneier says software vendors get away with more defects than other industries do. "Chrysler won't [knowingly] sell you a car with an [unsafe] feature--they know if you get into an accident, they'll be held liable. But there is no such product liability in software."

Schneier adds that software makers are slow to learn from mistakes. "Buffer overflows are the poster child of why problems aren't getting better," he says. "They were discovered in the 1960s and were first used to attack computers in the 1970s.... Here we are 40 years later, and buffer overflows are the most common security problem. And that's an easy problem to fix. If you are a software vendor, there is zero excuse for buffer overflows."

But vendors have little legal incentive to address problems--no current laws require vendors to fix holes. Of course, if a hole in a personal finance package results in users' data being open to perusal, for instance, the vendor will have to issue a patch, or suffer consumers' ire. But many holes are less obvious--such as ones that let a cracker use your PC to attack a Web site. In that case, you may never know your system has been compromised.

Schneier says the only things that will force vendors to produce better software are consumer lawsuits and higher insurance premiums for software makers and the businesses that use their products.

Insurance broker J.S. Wurzler Underwriting Managers now charges higher premiums for clients using Microsoft's IIS and Windows NT, but no security-related consumer suits seem to be pending against software makers. Vendors anticipating the sting of litigation are taking pains to protect themselves. Terms-of-service agreements that users must click through before installing software carry "limitation of liability" clauses. Accepting such agreements means you may be relinquishing your right to sue. Enforcement of these clauses has not been tested in court, however.

"Liability would be a great incentive," says Levy, "but...even under the best efforts, software will still have some errors. So are we placing [software vendors] in a position in which they simply can't deliver?"

In the final analysis, Levy says, consumers may have more clout than they think. "Microsoft is very customer-focused," he says. "If customers asked them for security, or if they voted with their wallets, I believe the company would pay attention. But even with all of the press about security problems in Microsoft products, customers simply don't view security as a high priority. Or at least they don't make that known for Microsoft to make it a priority."

Perhaps it's time consumers let software vendors know how they feel about security--and take their business elsewhere when it appears that no one is listening. Of course, going elsewhere won't always be a viable option, especially in a Microsoft-centric world. But until software security improves, it's mostly up to users to defend themselves.