Worms are a problem on the net. Even users of operating systems which tend
not to be afflicted by this sort of malware are affected when worm-caused
traffic clogs the net or brings down sites of interest. So everybody has
an interest in finding ways to reduce the number of worm infections.
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
Open Source software is often developed by, or with substantial
participation from particularly security-conscious users. These
users have strong incentives to participate in initial development
in order to prevent having to rework the product later or create a
more secure "fork."
Open source does not directly address the problem of user flaws,
and particular projects can be as rushed and buggy as proprietary
software. However, because it is open and modifiable by anyone, it
is at least capable of responding to those users who are
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
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 TeX. 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
to post comments)