Liability for Software Vulnerabilities

Richard Warner

Chicago-Kent College of Law

rwarner@kentlaw.edu

Vulnerability Defined

A vulnerability is a feature one can exploit to gain unauthorized access.

Claims: The law’s ability to decrease

vulnerabilities in software is limited. We have to rely on market solutions.

1. Inherently Complex (Daedal) It is impossible to write complex

software without creating vulnerabilities. But there can be different rates of error. Errors reduced by good engineering

procedures and practices. There is a line between reasonably

programmed and unreasonably programmed software. But a blurry line.

2. System Designers Make Mistakes As in any profession, programmers

differ in skill. A grandmaster chess player may easily find

a vulnerability in a defense that a master overlooks.

Relatively unskilled programmers still get jobs.

3. The Error Correction Problem Bridge building: an engineer discovers that the

value of an important variable is not correct. Typically, the correction will typically not make the

approximation to correctness worse.

Software: Error correction is discrete: A “0” replaces a “1” or vice versa. Error correction may make matters worse.

4. Network Complexity

Software which seems secure when tested in a stand-alone environment may contain or create vulnerabilities in the environment in which it is actually used.

It can be extraordinarily difficult to predict what software will do when it is embedded in a complex network. The following diagram—a very small part of one

corporate network—illustrates the degree of complexity involved.

AppFarm

10.222.22.222/33

Subnet v - AP State

Subnet 6 - VIP's on APPreprod:216.64.219.0/26

DMZ:216.64.220.0/24DMZ:216.64.221.0/24

Nameout01-xx DOEout02-int

DOEin4-intDOEin3-int

GIG

VLAN Trunk

Cisco 7204VXRrHostef-eg110.999.0.93

Corp OfficeAtlanta, IL

Corp OfficeAtlanta, IL

HOSTING SERVICE

BGP AS 65029

BGP AS 65025

INTERNET

Address TranslationSubnet w

Xx.xxx.x.xx/xx

Switch Interfaces-Subnet wwXx.xxx.x.xxx/xx

Subnet 910.456.78.01/27

Subnet1010.999.0.22 /18

Subnet 1310.999.0.80 /28

Cisco 2924XLLayer 2 Switches

-Unnumbered-

Xx.xxx.x.x Xx.xxx.x.x

10.123.4.10/xx10.123.4.5/34

Subnet y

Cisco 2924XLLayer 2 Switches- Unnumbered -

Subnet xa/xx

100 Mbps Ethernet - 5 Mbps base

XXX

Subnet xc/yy

Subnet xb/bb

.230

xxx .234

xxx

xxxxxx

NAME1 ACCESS1XXX.XX.XXX.XXX

IDS SD

Sun SP RCserver 5

xxx

100 Mbps Ethernet - 5 Mbps base

Subnet 1A - 000.00.000.000/00

Subnet 1B - 111.11.111.111/11

Subnet 1C - 222.22.222.222/22

Subnet 2 - 333.33.333.333/33

Preprod:: 232.33.433.4/34

DMZ: 444.34.234.5/66

DMZ: 887.83.879.5/77

swhost-intdmz1

Xxx.xx.xxx.xxx

Hosting Access2Xxx.xx.xxx.xx/xx

SiSi SiSiContent SwitchesCisco CS11000

Xx.xxx.x.xx

216.64.216.254

Xx.xxx.x.xx

AP-VV1

Subnet ww

Unnumbered Unnumbered

Subnet 14 FW 1 & 2 StateXx.xxx.x.xxx Xx.xxx.x.xxx

Cisco 3640 Routers

Nokia IP650Checkpoint Firewalls

10.999.0.113 10.999.0.114

SiSi

Subnet 8

Subnet 9

AB-EFG

Swabc-xxx

Subnet 9

SiSi

AP-VV3

Cisco 6509

Content SwitchesCisco CS11000

AP-VV4

Xx.xxx.x.xxx/xx

10.999.0.34 10.999.0.34

Subnet 7 AP 3 & 4 State10.999.0.16/29

Nokia IP650Checkpoint Firewalls

10.999.1.253/24

10.999.0.45 10.999.0.46

Subnet 15 FW 3 & 4 State10.999.0.73/29 10.999.0.74/29

10.999.0.49 10.999.0.50

GIG

VLAN Trunk

Subnet 10

Subnet 12

Subnet 13

swHost-appdmz2Subnet 10

Subnet 12

Subnet 13

SiSi

10.999.0.55

10.999.0.90

swhost-appdmz1Cisco 6506

SiSi

AP-VV5 AP-VV610.999.0.55

10.999.0.91

Subnet 11 AP 5 & 6 State10.999.0.64/29

MSFC10.999.0.82

MSFC10.999.0.83

Cisco 7204VXRrHost-eg2

10.999.0.94

Cisco 7204VXRrHost-sc1

10.999.0.254

Cisco 7204

DS-3MCI:1X-444-fZ5-1111

Subnet 20

Subnet 21

10.999.4.0/24

10.999.5.0/24

Subnet ww

Subnet 8

Subnet 9

Xx.xxx.x.xxx/xx

Xx.xxx.x.xxx/xx

Subnet 20

Subnet 21

10.999.4.0/24

10.999.5.0/24

Xx.xxx.x.xxx Xx.xxx.x.xxx

10.999.0.32/28 10.999.0.32/28

Cisco 7204VXRr4442es1

10.999.224.43

Trunk Cisco 7204VXRrHost-sc2

10.999.0.250

Cisco 7204VXRr4442es2

10.999.224.104

RB1 switch (area 0)

RB2 switch (area 0)

Other area 0 backbone routers

r4442-appdmz1 r4442-appdmz2

Hosting AssignedAddress Space

Xxx.xx.xxx.xxx/xx

Possible Legal Responses

(1) Products liability (2) Negligence (3) Certification or licensing regime (1) and (2) treat with considerable

deference cases in which socially useful activities create unavoidable harm.

Products Liability

The manufacturer is liable for the foreseeable damage caused by a defect in a product. No requirement of negligence.

A defect is a tendency to cause physical harm beyond that contemplated by an ordinary user whose knowledge of the product’s characteristics

consists of what is commonly known by foreseeable users of the

product.

Problems Difficulties in defining what counts as

defective. Where as practical matter impossible to create a

non-defective produce, the law is reluctant to impose products liability.

Small losses for any one plaintiff. Slowness of the process to bring about

change. Causation problems

“It wasn’t my software; it was your implementation.”

Negligence

Standard of reasonableness Industry norms

reasonable unclear unreasonable

An Initial Hurdle to Tort Liability The economic loss rule: without a physical

impact, there is no tort recovery for purely economic loss.

Rationales: to limit losses to a bearable amount. to allocate responsibility for the loss in an efficient

manner.

Tort

Extent of physical impact

Economic impact

Drop the Economic Loss Rule? To apply tort liability to software, we would

have to drop the economic loss rule in those cases.

Would the resulting liability be excessive?

Would Negligence Liability Really Help? The Hacker Wins the Race If the software has 100 vulnerabilities, you need to

find all, or at least most, of them to be secure against unauthorized access.

The hacker just needs to find one that you have not yet found.

In the race with the hacker, the hacker will almost certainly win.

See the SANS http://www.sans.org/top25-programming-errors/.

Applications: Legacy Systems Old systems can be difficult or expensive to

update. Many systems run outdated, insecure

software. As Ross Anderson notes.

What counts as negligence where the industry standard is to run outdated, “insecure” programs? Scare quotes because “insecure” here is a

normative conclusion: not as secure as it should be.

Patching

When is it negligent not to patch? Home machines versus business networks. The patching decision in a complex network can

be a very difficult technological and business call. Verizon case.

But this is an extreme.

What Counts as Negligence When Documentation is Inadequate? Most products do not clearly document

their out-of-the-box security configuration security assumptions security capabilities, recommended practices.

The tech support issue: “Vendors are naturally inclined to hold out until users pay for

support and to provide minimal documentation so as to increase the number of support paid support calls. Vendors claim that they have to pay their support costs, but making effective user interfaces and completely documenting software can nearly eliminate support calls.”

Strebe and Perkins, Network Address Translation There are price discrimination efficiencies from this approach.

Unclarity Problems

Unclarity in the standard could fail to deal adequately with market pressures. inhibit innovation. be too lenient in regard to legacy systems. inhibit price discrimination in selling tech support.

Causation problems “It wasn’t my software; it was your

implementation.”

Contractual Protections for Vendors Even if we instituted a negligence regime of

some robustness, vendors contractual disclaim liability.

A typical example follows.

In re America Online Inc. Version 5.0 Software Litigation In In re America Online Inc. Version 5.0

Software Litigation, 168 F.Supp.2d 1359, America Online (AOL) distributed software that cut off non-AOL Internet access, disrupted local area networks, and interfered with other applications and thereby causing computers to crash. AOL distributed the software accompanied by a clickwrap Terms of Service (TOS) agreement. The court noted that the

The Disclaimer

The court noted that the TOS Agreement stated: “[M]ember expressly agrees that the use of

AOL, AOL software, and the Internet is at member's sole risk." . . . With respect to disputes relating to the software, the TOS Agreement provides, "AOL's entire liability and your exclusive remedy ... shall be the replacement of any AOL software found to be defective." . . .”

The Disclaimer

“If the consumers have any other dispute, "[Y]our sole and exclusive remedy ... is the cancellation of your account." . . . The TOS Agreement also purports to limit AOL's liability for consequential damages. . . . According to AOL, . . . these provisions prevent the consumers from seeking punitive damages, compensatory damages, disgorgement, injunctive relief, and attorneys' fees.”

168 F.Supp.2d 1359, 1361 (S.D. Florida 2001).

The Law’s Attitude

The law generally enforces such disclaimers in the defective product context, where the vendor is unaware, and should not have been aware, of the defect.

The risk of loss from the defect shifts to the buyer.

In Favor of the Shift Assume (for now) that the vendor has a

sufficient market incentive to make a reasonable effort to produce a non-defective product.

What happens if we do not allow the vendor to shift the risk of loss onto the buyer? The cost of the product rises. Defects are inevitable, and the seller will be liable. So the seller takes the expected legal loss into

account in setting the price. Low-risk buyers subsidize high-risk buyers.

In Favor of the Shift

What happens if we allow the vendor to shift the risk? The cost does not rise. Buyers who wish to insure against the risk of loss. Low-risk buyers do not subsidize high-risk buyers.

But this analysis assumes sufficient market pressure to make a reasonable effort to produce non-defective software. Is this true?

4. Market Pressures

Network effects It is critical to be first to market where network

effects are strong, as in software. Insufficient testing and debugging.

Changes in specifications after project begun Buyers insistence on usability.

Buyers insist on usability. Security often reduces usability, but Buyers undervalue security.

It is difficult for buyers to evaluate security features.

5. Group Programming

Complex software cannot be built by a single person. It is programmed by a group.

The programming process suffers from the communication and coordination problems inherent in groups. 1999 Mars mission

Use of old code Ariane 5

Security software: Lemons market?

In a lemons market, bad may drive out good. The idea: Consumers cannot pre-purchase tell the

difference between a good product and a lemon; so

the price drops (the expected value of the purchase is reduced by the expected value of getting a lemon); and

good products disappear from the market.

Security software: Lemons market? Bruce Schneier claims this happens in

the computer security market. You may not be aware failures in your

security. Buyers cannot tell good from bad products.

Certification As A Solution The National Security Telecommunications

Advisory Committee, Internet Security/Architecture Task Force Report calls for certification.

Create by statute an organization that promulgates manufacturing standards and

certifies that manufacturers follow them, where

violators are fined (liability for actual or foreseeable damage would be excessive).

Is Certification Feasible? Problem: The software industry changes so

fast that substantive standards are difficult to formulate. Solution: Require security testing and

documentation of security features and risks. Problem: What counts as adequate security

testing and documentation? Overall: certification lacks a

convincing record of success.

Licensing Requirements

We license many professionals. Why not network administrators? And,

perhaps, programmers? Licensing requirements impose professional

duties that constrain the exercise of professional judgment.

Assessment of Certification and Licensing Evidence form other areas suggests that

these approaches have limited value. We may want to pursue these options, but we

cannot rely on them as a complete solution.

Market Solutions: Many Minds and Money Where Your Mouth Is A market solution relies primarily on

monetary, non-legal incentives to achieve a desired result.

There are three market solutions.

First Market Solution:Open Source Software Software is “open source” if its source code is

publicly available. Open source software may be the product of many

programmers, scattered all over the world, who contribute to the source code.

Open source software has advantages. Fewer defects No proprietary problems.

Legal issues: Liability for intellectual property violations

Sco Group v. IBM

Open Source Economics Open source software works best when it is

Based on non-proprietary techniques No “blends” of open source and proprietary code.

Subject to network effects The application is sensitive to failure Verification requires peer review Sufficiently important (business critical) that people will

cooperate to find bugs Eric Raymond, The Magic Cauldron

Security has all the above features (Anderson). Many software vendors pursue an anti-interoperability

strategy incompatible with open source software. Prohibitions on reverse engineering in End User License

Agreements.

Second Market Solution:Vulnerability Disclosure Markets A vulnerability disclosure market provides a

mechanism for those who discover vulnerabilities to communicate them to software manufacturers/vendors.

There four possibilities.

First Possibility: Market-Based A business—like iDefense—pays for

information about the existence of vulnerabilities and communicates this information to its clients. Markets are generally very successful in

aggregating dispersed information. They are accurate and efficient. Unless precautions are taken, clients could be hackers.

This is true also in all following cases.

iDefense

Second Possibility:CERT-type Organizations No money is charged for the disclosure of the

vulnerability. One would expect this not to perform as well as a

market mechanism. Kannan, Telang, and Xu, Economic Analysis of the

Market for Software Vulnerability Disclosure, contend CERT-type organizations sometimes outperform market mechanisms, but they assume that relevant information is costlessly available. This ignores precisely that at which markets excel. Available on SSRN.

Third Possibility:Consortium Mechanism

Those concerned to gain information about vulnerabilities form a consortium. Members may share information for free.

Examples Information Sharing Analysis Centers (ISACs) Annual fees in the $10,000’s.

Similar to CERT-type organizations with the added complexity of conflicting business motives.

Fourth Possibility:Federally Funded Centers This does not exist. The center would pay for the discovery of

vulnerabilities, but Would not charge for the disclosure of the

information. Kannan, Telang, and Xu, Economic Analysis of the

Market for Software Vulnerability Disclosure, contend this type of approach performs best, but again they assume that relevant information is costlessly available.

Third Market Solution: Prediction Markets A prediction market would accomplish the purpose. In the market, investors buy futures in which the

speculate on which products will have this or that type of vulnerability.

Such markets have proven remarkably accurate in predicting a wide variety of events.

The prediction markets might work well where there are active disclosure markets which reveal the existence of vulnerabilities.

An Example Why not set up a prediction market in which

investors by futures on when vulnerabilities will be discovered.

Investors could speculate on the time, number, and rank order in the list.

The activity in the market could guide purchase decisions prior to discovery of the vulnerability.