De-worming the net

Researcher Douglas Barnes has taken a look at the problem and come up with a new set of recommendations. His work is written up in this 50-page PDF document. We took a look at his work, with an emphasis on its implications for the free software community.

The paper starts by pointing out that market forces have failed to put an end to the worm problem. Indeed, the characteristics of the software market tend to encourage the creation and use of vulnerable software. The company which wins in the market is the one which is able to get its product adopted first and establish the de facto standards. So manufacturers have a great incentive to emphasize features and time to market over security. Since moving away from buggy software can be difficult, software vendors tend not to pay much of a cost for security incidents which involve their products.

The author notes that free software is a pleasant exception to this problem:

Some commenters (notably Bruce Schneier) have proposed that software vendors should be made legally liable for flaws in their products. At that point, they will have a strong motivation to take the time to get things right. Mr. Barnes, however, thinks that the liability approach will not work. Many quirks in the U.S. justice system make it hard to win a suit based on software flaws; these include the enforceability of "click-wrap" licenses, the notion that the vendor is not the real cause of security problems (the crackers are), and the interesting precedent that loss of data is not considered to be "physical harm." The potential harm to free software projects is also mentioned as a reason to avoid the litigation approach.

So how is the worm problem to be solved? Mr. Barnes has three suggestions:

• Bug Bounties. The success of bounties offered to those who report security-related bugs in programs like Netscape and djbdns is remarked upon. Mr. Barnes notes, however, that software companies are generally uninterested in offering bug bounties. So, he says, bounties should be imposed upon them by way of a publicly-administered program. Software publishers would contribute to a fund which would be used to pay bounties.

• Quality standards for software. The idea here is that worms should be treated as if they were an environmental issue; some sort of regulatory agency would be empowered to impose standards upon software. No suggestions for specific standards are made.

• Penalties for use of insecure software. Users, this paper claims, do not sufficiently value security in software. To help them see the error of their ways, a penalty would be imposed on users who insist on running software known to be insecure.

Establishing this sort of regulatory regime looks like an uphill battle, to say the least. That is likely to be a good thing; the imposition of a heavy-handed, low-clue regulatory agency upon the software industry could easily do more harm than good. But the community can - and does - benefit from these ideas already.

Free software projects with the requisite funding have used bug bounties before; the original such bounty may well have been Donald Knuth's rewards to those who found bugs in T_eX. Even in the absence of cash bounties, numerous white-hat researchers can be seen digging for security bugs in free software for the reputation benefits and the sheer fun of it. Perhaps groups like OSDL could consider offering bounties on security bugs in certain bodies of code as a way of encouraging this process.

Free projects often have software quality standards as well, though they vary greatly from one project to the next. Peer review can help to find any of a number of obvious mistakes; in some projects, code is increasingly unlikely to be accepted if it is not seen as being up to certain standards. Many project could benefit from stronger standards, however, and from some sort of documentation of just what their standards are.

The community has little sympathy for penalizing users for their software choices, certainly. Still, that approach can be seen in some corners. Firefox will nag at people who use a version known to have vulnerabilities. Hopelessly insecure packages become unsupported and unavailable from distributions, forcing users to find an alternative. But the community has put most of its effort into an alternative approach: making it as easy as possible to run a system without known vulnerabilities. Most modern distributions can be kept updated with little or no effort; it's almost harder not to patch them.

So, perhaps, the free software community already has most of the tools it needs to contribute toward a worm-free net. No regulatory action required. All that is needed is to get the rest of the software community to catch up.