Redress for Software Failures
So far, we have considered programs,
algorithms, and data as objects of ownership. But these objects vary in
quality, and some of the legal issues involved with them concern the degree to
which they function properly or well. In fact, people have legitimate
differences of opinion on what constitutes "fair," "good,"
and "prudent" as these terms relate to computer software and
programmers and vendors. The law applies most easily when there is broad
consensus. In this section we look closely at the role that quality plays in
various legal disputes. At the same time, we also look at the ethical side of
software quality, foreshadowing a broader discussion on ethics later in this
chapter.
Program development is a human process of
design, creation, and testing, involving a great deal of communication and
interaction. For these reasons, there will always be errors in the software we
produce. We sometimes expect perfect consumer products, such as automobiles or
lawn mowers. At other times, we expect products to be "good enough"
for use, in that most instances will be acceptable. We do not mind variation in
the amount of cheese in our pizza or a slight flaw in the glaze on a ceramic
tile. If an instance of a product is not usable, we expect the manufacturer to
provide some appropriate remedy, such as repair or replacement. In fact, the
way in which these problems are handled can contribute to a vendor's reputation
for quality service; on the rare occasions when there is a problem, the vendor
will promptly and courteously make amends.
But the situation with software is very
different. To be fair, an operating system is a great deal more complex than
many consumer products, and more opportunities for failure exist. For this
reason, this section addresses three questions:
What are
the legal issues in selling correct and usable software?
What are
the moral or ethical issues in producing correct and usable software?
What are
the moral or ethical issues in finding, reporting, publicizing, and fixing
flaws?
In some ways, the legal issues are evolving.
Everyone acknowledges that all vendors should produce good software, but that
does not always happen. The more difficult concerns arise in the development
and maintenance communities about what to do when faults are discovered.
Selling Correct Software
Software is a product. It is built with a
purpose and an audience in mind, and it is purchased by a consumer with an
intended use in an expected context. And the consumer has some expectations of
a reasonable level of quality and function. In that sense, buying software is
like buying a radio. If you buy a faulty radio, you have certain legal rights
relating to your purchase and you can enforce them in court if necessary. You
may have three reactions if you find something wrong with the radio: You want
your money back, you want a different (not faulty) radio, or you want someone
to fix your radio. With software you have the same three possibilities, and we
consider each one in turn.
To consider our alternatives with software, we
must first investigate the nature of the faulty code. Why was the software bad?
One possibility is that it was presented on a defective medium. For example,
the CD may have had a flaw and you could not load the software on your
computer. In this case, almost any merchant will exchange the faulty copy with
a new one with little argument. The second possibility is that the software
worked properly, but you don't like it when you try it out. It may not do all
it was advertised to do. Or you don't like the "look and feel," or it
is slower than you expected it to be, or it works only with European phone
numbers, not the phone scheme in your country. The bottom line is that there is
some attribute of the software that disappoints you, and you do not want this
software.
The final possibility is that
the software malfunctions, so you cannot use it with your computer system.
Here, too, you do not want the software and hope to return it.
I Want a Refund
If the item were a radio, you
would have the opportunity to look at it and listen to it in the shop, to
assess its sound quality, measure its size (if it is to fit in a particular
space), and inspect it for flaws. Do you have that opportunity with a program?
Probably not.
The U.S. Uniform Commercial
Code (UCC) governs transactions between buyers and sellers in the United
States. Section 2-601 says that "if the goods or the tender of delivery
fail in any respect to conform to the contract, the buyer may reject
them." You may have had no opportunity to try out the software before
purchase, particularly on your computer. Your inspection often could not occur
in the store (stores tend to frown on your bringing your own computer, opening
their shrink-wrapped software, installing the software on your machine, and
checking the features). Even if you could have tried the software in the store,
you may not have been able to assess how it works with the other applications
with which it must interface. So you take home the software, only to find that
it is free from flaws but does not fit your needs. You are entitled to a
reasonable period to inspect the software, long enough to try out its features.
If you decide within a reasonably short period of time that the product is not
for you, you can cite UCC §2-601 to obtain a refund.
More often, though, the
reason you want to return the software is because it simply is not of high
enough quality. Unfortunately, correctness of software is more difficult to
enforce legally.
I Want It to Be Good
Quality demands for mass
market software are usually outside the range of legal enforcement for several
reasons.
Mass-market software is
seldom totally bad. Certain features may not work, and faults may prevent some
features from working as specified or as advertised. But the software works for
most of its many users or works most of the time for all of its users.
The manufacturer has
"deep pockets." An individual suing a major manufacturer could find
that the manufacturer has a permanent legal staff of dozens of full-time
attorneys. The cost to the individual of bringing a suit is prohibitive.
Legal remedies typically
result in monetary awards for damages, not a mandate to fix the faulty
software.
The manufacturer has little
incentive to fix small problems. Unless a problem will seriously damage a
manufacturer's image or possibly leave the manufacturer open to large damage
amounts, there is little justification to fix problems that affect only a small
number of users or that do not render the product unfit for general use.
Thus, legal remedies are most
appropriate only for a large complaint, such as one from a government or one
representing a large class of dissatisfied and vocal users. The "fit for
use" provision of the UCC dictates that the product must be usable for its
intended purpose; software that doesn't work is clearly not usable. The UCC may
help you get your money back, but you may not necessarily end up with working
software.
Some manufacturers are very
attentive to their customers. When flaws are discovered, the manufacturers
promptly investigate the problems and fix serious ones immediately, perhaps
holding smaller corrections for a later release. These companies are motivated
more by public image or moral obligation than by legal requirement.
Trope [TRO04] proposes a warranty of cyberworthiness.
The warranty would state that the manufacturer made a diligent search for
security vulnerabilities and had removed all known critical ones. Furthermore,
the vendor will continue to search for vulnerabilities after release and, on
learning of any critical ones, will contact affected parties with patches and
work-arounds. Now, a maker is potentially liable for all possible failings, and
a major security-critical flaw could be very costly. Trope's approach limits
the exposure to addressing known defects reasonably promptly.
Reporting Software Flaws
Who should publicize flawsthe
user or the manufacturer? A user might want the recognition of finding a flaw;
delaying the release might let someone else get that credit. A manufacturer
might want to ignore a problem or fail to credit the user. And either could say
the other was wrong. And how should these flaws be reported? Several different
viewpoints exist.
What You Don't Know Can Hurt You
The several variants of Code
Red in 2001 sparked a debate about whether we should allow full disclosure of the
mechanisms that allow malicious code to enter and thrive in our systems. For
example, the first variant of Code Red was relatively benign, but the third and
fourth variants were powerful. When the first Code Red variant appeared, it was
studied by many security analysts, including those at eEye Digital Security in
Aliso Viejo, California. In an effort to pressure vendors and software managers
to take seriously the threats they represent, eEye practices full disclosure of
what it knows about security flaws.
However, some observers claim
that such open sharing of information is precisely what enables hackers to
learn about vulnerabilities and then exploit them. Several developers suspect
that eEye's openness about Code Red enabled the more powerful variants to be
written and disseminated [HUL01].
Scott Culp [CUL01], Microsoft's manager of Windows security,
distinguishes between full disclosure and full exposure; he thinks that source
code or detailed explanations of a vulnerability's concept should be protected.
And many security analysts encourage users and managers to apply patches right
away, closing security holes before they can be exploited. But as we saw in Sidebar 3-5, the patches require resources and
may introduce other problems while fixing the initial one. Each software-using
organization must analyze and balance the risks and cost of not acting with the
risks and costs of acting right away.
The Vendor's Interests
Microsoft argues that
producing one patch for each discovered vulnerability is inefficient both for
the vendor and the user. The vendor might prefer to bundle several patches into
a single service pack or, for noncritical vulnerabilities, to hold them until
the next version. So, Microsoft would like to control if or when the report of a
vulnerability goes public.
Craig Mundie, Microsoft's
Chief Technology Officer, suggests a stronger reason to minimize disclosure of
vulnerability information. "Every time we become explicit about a problem
that exists in a legacy product, the response to our disclosure is to focus the
attack. In essence we end up funneling them to the vulnerability." [FIS02a] Scott Culp argued [CUL01] that "a vendor's responsibility is
to its customers, not to a self-described security community." He opposed
what he called "information anarchy,… the practice of deliberately
publishing explicit, step-by-step instructions for exploiting security
vulnerabilities without regard for how the information may be used." But
he also acknowledged that the process of developing, distributing, and applying
patches is imperfect, and his own company "need[s] to make it easier for
users to keep their systems secure."
Users' Interests
David Litchfield, a security
researcher noted for locating flaws in vendors' programs, announced in May 2002
that he would no longer automatically wait for a vendor's patch before going
public with a vulnerability announcement. Citing "lethargy and an
unwillingness to patch security problems as and when they are found," [FIS02b] Litchfield criticized the approach of
holding fixes of several vulnerabilities until enough had accumulated to
warrant a single service pack. He makes the point that publicized or not, the
vulnerabilities still exist. If one reporter has found the problem, so too
could any number of malicious attackers. For a vendor to fail to provide timely
patches to vulnerabilities of which the vendor is aware leaves the users wide
open to attacks of which the user may be unaware.
Litchfield's solution is to
put pressure on the vendor. He announced he would give vendors one week's
notice of a vulnerability before publicizing the vulnerabilitybut not the
details of how to exploit itto the world.
"Responsible" Vulnerability Reporting
Clearly the conflicting
interests of vendors and users must meet at some compromise position. (For an
example of how vulnerability disclosure does not work, see Sidebar 11-3.) Christey and Wysopal [CHR02] have proposed a vulnerability reporting
process that meets constraints of timeliness, fair play, and responsibility. They
call the user reporting a suspected vulnerability a "reporter" and
the manufacturer the "vendor." A third partysuch as a computer
emergency response centercalled a "coordinator" could also play a
role when a conflict or power issue arises between reporter and vendor.
Basically, the process requires reporter and vendor to do the following:
Sidebar
11-3: Flaw? What Flaw? I Don't See a Flaw.
In July 2005, security researcher Michael
Lynn made a presentation to the Black Hat security conference. As a researcher
for Internet Security Systems (ISS) he had discovered what he considered
serious vulnerabilities in the underlying operating system IOS on which Cisco
based most of its firewall and router products. ISS had made Cisco aware of the
vulnerabilities a month before the presentation, and the two companies had been
planning a joint presentation there but canceled the presentation.
Concerned that users were in jeopardy
because the vulnerability could be discovered by attackers, Lynn presented
enough details of the vulnerability for users to appreciate its severity. ISS
had tried to block Lynn's presentation or remove technical details, but he
resigned from ISS rather than be muzzled. Cisco tried to block the
presentation, as well, demanding that 20 pages be torn from the conference
proceedings. Various sites posted the details of the presentation, lawsuits
ensued, and the copies were withdrawn in settlement of the suits. The incident
was a public relations nightmare for both Cisco and ISS. (For an overview of
the facts of the situation, see Bank [BAN05].)
The issue remains: How far can or should
a company go to limit vulnerability disclosure? On the one hand, a company
wants to limit disclosure, while on the other hand users want to know of a
potential weakness that might affect them. Researchers fear companies will not
act quickly to close vulnerabilities, thus leaving customers at risk.
Regardless of the points, the legal system is not the way to address
disclosure.
Computer security is not the only domain
in which these debates arise. Matt Blaze, a computer security researcher with
AT&T Labs investigated physical locks and master keys [BLA03]; these
are locks for organizations such as college dormitories and office buildings, in
which individuals have keys to single rooms, and a few maintenance or other
workers have a single master key that will open all locks. Blaze describes a
technique that can find a master key for a class of locks with relatively
little effort because of a characteristic (vulnerability?) of these locks; the
attack finds the master key one pin at a time. According to Schneier [SCH03]
and Blaze, the characteristic was well known to locksmiths and lock-picking
criminals, but not to the general public (users). A respected cryptographer,
Blaze came upon his strategy naturally: His approach is analogous to a standard
cryptologic attack in which one seeks to deduce the cryptographic key one bit
at a time.
Blaze confronted an important question: Is it better to document a
technique known by manufacturers and attackers, but not to users, or to leave
users with a false sense of security? He opted for disclosure. Schneier notes
that this weakness has been known for over 100 years and that several other
master key designs are immune to Blaze's attack. But those locks are not in
widespread use because customers are unaware of the risk and thus do not demand
stronger products. Says Schneier, "I'd rather have as much information as
I can to make informed decisions about security."
The vendor must acknowledge a
vulnerability report confidentially to the reporter.
·
The vendor must agree that the vulnerability exists (or argue
otherwise) confidentially to the reporter.
·
The vendor must inform users of the vulnerability and any available
countermeasures within 30 days or request additional time from the reporter as
needed.
·
After informing users, the vendor may request from the reporter a
30-day quiet period to allow users time to install patches.
·
At the end of the quiet period the vendor and reporter should agree
upon a date at which time the vulnerability information may be released to the
general public.
·
The vendor should credit the reporter with having located the
vulnerability.
·
If the vendor does not follow these steps, the reporter should work
with a coordinator to determine a responsible way to publicize the
vulnerability.
Such a proposal can only have
the status of a commonly agreed-on process, since there is no authority that
can enforce adherence on either users or vendors.
Quality Software
Boris Beizer, a consultant,
has said, "Software should be shipped with bugs. The zero-defect notion is
mythological and theoretically unachievable. That doesn't mean shipping
ill-behaved or useless software; it means being open with users about the bugs
we find, sending notices or including the bug list, publishing the workarounds
when we have them, and being honest and open about what we have and haven't yet
tested and when we do and don't plan to test in the near future." [COF02]
The whole debate over how and
when to disclose vulnerabilities avoids the real issue. The world does not need
faster patches, it needs better software with fewer vulnerabilities after
delivery to the user. Forno [FOR01]
says, "The most significant danger and vulnerability facing the Wired
World is continuing to accept and standardize corporate and consumer computer
environments on technology that's proven time and again to be insecure,
unstable, and full of undocumented bugs ('features') that routinely place the
Internet community at risk."
In January 2002, Bill Gates,
CEO of Microsoft, announced that producing quality software with minimal
defects was his highest priority for Microsoft, ahead of new functionality. His
manager of development of the XP operating system announced he was requiring
programmers involved in development of XP to attend a course in secure
programming. Did the initiative work? In one five-day period in June 2002,
Microsoft released six separate patches for security vulnerabilities. In
November 2004, Microsoft went to once-a-month patch releases and has
distributed an average of two to three new critical patches each month since
then.
The issue is not how promptly
a vulnerability is patched or how much detail is released with a vulnerability
announcement. The issue is that, as the Anderson report [AND72] noted over three decades ago,
"penetrate and patch" is a fatally flawed concept: after a flaw was
patched, the penetrators always found other old flaws or new flaws introduced
because of or in the patch. The issue is technical, psychological,
sociological, managerial, and economic. Until we produce consistently solid
software, our entire computing infrastructure is seriously at risk.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.