RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (12/12/88)
RISKS-LIST: RISKS-FORUM Digest Sunday 11 December 1988 Volume 7 : Issue 91
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
More on Proper British Programs (Nancy Leveson)
Re: Vendor Liability, and "Plain Vanilla" configurations (Jay Elinsky)
Manufacturers' Responsibilities for Security (Lynn R Grant)
Hacker enters U.S. lab's computers (George Wood via Werner Uhrig)
Computer Virus Eradication Act of 1988 (Don Alvarez, from VIRUS-L)
They did it: Speed-Thru Tollbooths (Robert Steven Glickstein)
Re: Toll Road information collection
(Brint Cooper, Scott E. Preece, John Sullivan)
Re: Subways that "know" who's on board (Chris Hibbert)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) /
get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95).
----------------------------------------------------------------------
Date: Fri, 09 Dec 88 13:00:37 -0500
From: leveson@electron.LCS.MIT.EDU
Subject: More on Proper British Programs
You probably all know about the MoD draft standard in Great Britain requiring
formal verification of safety-critical software. Well, here is another one.
I was asked to consult on the safety of a microwave landing system, and
they have just sent me a copy of a draft attachment to an international
standard for MLS systems by the ICAO (international organization overseeing
such aircraft systems). This may no longer be a draft -- there is no date
on it and the company implied that they had to follow it. As you can see
from the following, there is an "out," but the sophistication of the standard
is a surprise to me (most American software standards are abysmal). Since
the ICAO must certify these systems before they are used, the standard has
teeth and could be enforced quite strictly (unlikely, but ...). The following
are some interesting excerpts:
"... [Software] must be developed systematically in such a way that its
behavior, under all possible conditions, can be established by logical
reasoning (to a level of formality appropriate to the application).
"... The programming should be performed in such a way that it is easily
possible to establish the correspondence between the programme and its
design and to verify its correctness with respect to its specification
by logical reasoning (possibly supported by software tools).
"... The interface of every software module with its enclosing environment
should be explicitly stated in a preamble within its code, as well as in the
design documentation. Where possible, a formal specification (e.g., in
terms of pre- and post- conditions) should be given.
"... Consistency of the code and its comments with the specification and the
design documents should be checked, as formally and precisely as possible,
as each module is developed. Formal verification (i.e., proofs of
consistency between formal specifications of software modules and their
code) should be performed where possible. Otherwise, manual code
inspections or structured walk-throughs are essential. A software safety
analysis should be performed as part of the design and development using
at least one technique such as FMECA, fault tree analysis, or cause and
consequence analysis..."
------------------------------
Date: Tue, 6 Dec 88 17:05:38 EST
From: "Jay Elinsky" <ELINSKY%YKTVMX.BITNET@CUNYVM.CUNY.EDU>
Subject: Re: Vendor Liability, and "Plain Vanilla" configurations (RISKS-7.88)
Maybe GM and the other manufacturers *would* sell cars without seat belts and
warning buzzers, if there wasn't a *law* requiring them. So if we accept
this as a valid analogy (I'm not saying it is or isn't), then the conclusion
is that we need a law requiring computers to have adequate security.
Jay Elinsky, IBM T.J. Watson Research Center, Yorktown Heights, NY
[Affiliation for identification only]
------------------------------
Date: Sun, 4 Dec 88 16:46 EST
From: Lynn R Grant <Grant@DOCKMASTER.ARPA>
Subject: Manufacturers' Responsibilities for Security (RISKS-7.86)
Having been in the security software business for several years, I must take
some exception to Keith Hanlan's comments on manufacturer's responsibilities
for security. While I truly believe that some vendors use the excuses he
mentioned for not making their products secure, there is some merit to them.
Security is not free. Those of us in this business do the best we can to make
secure systems easy to use (at least the good ones among us do), but a wide
open system is usually easier to use. Security involves a tradeoff: it what
it costs you less than what you might lose without it. The customer may decide
it isn't worth the cost. He may be wrong, but it's still his decision.
As for bugs, bugs should be fixed. But design flaws that influence security
are trickier. For some reason, customers tend to find these flaws, and set up
their production systems so they depend upon them. Thus, when you fix them,
suddenly your customer's shops don't run anymore, and they get very irate. If
your competitors do not fix the problem in their software, your customers see
this as a feature, and it puts you at a competitive disadvantage. I can see
how some vendors might knuckle under to this pressure, figuring that fighting
for security ideals is of no use if all the customers flee for some less secure
system and cause the company to fold up.
Let me reiterate that this is not a wholesale defense of those who ignore
security in the name of ease of use (which may really be ease of
implementation). I just want to point out the pressures that exist in the
competitive arena of commercial software.
Lynn R. Grant, Technical Consultant, Computer Associates International, Inc.
Disclaimer: These opinions are my own, and may or may not reflect those
of my employer.
[One man's feature is another man's future. But one person's feature
can also be someone else's destruction. I am reminded of the multiple
index register instructions in the IBM 7090 that stopped working in the
7094 because they were `only features' and were not officially supported.
Anyone who lives by unsupported features may die the same way. PGN]
------------------------------
Date: Sat, 10 Dec 88 20:33:00 CST
From: wood@emmy.ma.UTEXAS.EDU (George Wood)
Subject: Hacker enters U.S. lab's computers
Resent-From: Werner Uhrig <werner@rascal.ics.UTEXAS.EDU>
Austin-American Statesman, Saturday, December 10, 1988, P. A29
Hacker enters U.S. lab's computers
By Thomas H. Maugh II, Los Angeles Times Service
A computer hacker has entered computers at the government's
Lawrence Livermore Laboratory in the San Francisco Bay area eight
times since last Saturday, but has not caused any damage and has not
been able to enter computers that contain classified information,
Livermore officials said Friday.
Nuclear weapons and the Star Wars defense system are designed
at livermore, but information about those projects is kept in
supercomputers that are physically and electronically separate from
other computers at the laboratory.
The hacker, whose identitiy remains unknown, entered the
non-classified computer system at Livermore through INTERNET, a
nationwide computer network that was shut down at the beginning of
November by a computer virus. Chuck Cole, Livermore's chief of
security, said the two incidents apparently are unrelated.
The hacker entered the computers through an operating system
and then through a conventional telephone line, He gave himself
"super-user" status, providing access to virtually all functions of
the non-classified computer systems.
Officials quickly limited the super-user access, although they
left some computers vulnerable to entry in the hope of catching the intruder.
"There has been no maliciousness so far," Cole said. "He
could have destroyed data, but he didn't. he just looks through data
files, operating records, and password files....It semms to be someone
doing a joy-riding thing."
------------------------------
Date: Mon, 5 Dec 88 16:43:12 EST
Sender: Virus Discussion List <VIRUS-L@IBM1.CC.Lehigh.Edu>
Subject: Computer Virus Eradication Act of 1988
[EXCERPT from VIRUS-L Digest V1 #33]
VIRUS-L Digest Monday, 5 Dec 1988 Volume 1 : Issue 33
Date: Mon, 5 Dec 88 11:11:06 EST
From: Don Alvarez <boomer@space.mit.edu>
Subject: Computer Virus Eradication Act of 1988
I just received a copy of HR-5061, a new bill being introduced
in the House by Wally Herger (R-CA) and Robert Carr (D-Mich.).
The text of the bill is included below (see disclaimer).
It sounds to me like there are some subscribers to VIRUS-L
who's background is more criminal law than computer science,
perhaps some of you could help the rest of us out with a little
commentary. Would this bill be helpful to you? Do you think
you would be able to get a conviction with it? Do you think
you would be able to recover your damages with it (and how would
you go about defining those damages if you were to use the law)?
If people are interested in sending their comments to the
authors, I include the name and address of the legislative
aide who has been working on this bill. If people would like
to e-mail their comments, you can send them to me and I will
mail them to him in a packet (be sure to include your name and
normal postal mail adress, as congress isn't on the net).
Don Alvarez, boomer@SPACE.MIT.EDU
- ------Start of Bill
100th Congress 2D Session H.R. 5061
To amend title 18, United States Code, to provide penalties for persons
interfering with the operations of computers through the use of programs
containing hidden commands that can cause harm, and for other purposes.
IN THE HOUSE OF REPRESENTATIVES July 14, 1988
Mr. Herger (for himself and Mr. Carr) introduced the following bill;
which was referred to the Committee on the Judiciary
A BILL
To ammend title 18, United States Code, to provide penalties for persons
interfering with the operations of computers through the use of programs
containing hidden commands that can cause harm, and for other purposes.
1 Be it enacted by the Senate and House of Representa-
2 tives of the United States of America in Congress assembled,
3 SECTION 1. SHORT TITLE.
4 This Act may be cited as the "Computer Virus Eradica-
5 tion Act of 1988".
- -------Page 2
1 SECTION 2. TITLE 18 AMENDMENT.
2 (a) IN GENERAL.- Chapter 65 (relating to malicious
3 mischief) of title 18, United States Code, is amended by
4 adding at the end the following:
5 "S 1368. Disseminating computer viruses and other harm-
6 ful computer programs
7 "(a) Whoever knowingly-
8 "(1) inserts into a program for a computer infor-
9 mation or commands, knowing or having reason to be-
10 lieve that such information or commands will cause
11 loss to users of a computer on which such program is
12 run or to those who rely on information processed on
13 such computer; and
14 "(2) provides such a program to others in circum-
15 stances in which those others do not know of the inser-
16 tion or its effects;
17 or attempts to do so, shall if any such conduct affects
18 interstate or foreign commerce, be fined under this title or
19 imprisoned not more than 10 years, or both.
20 "(b) Whoever suffers loss by reason of a violation of
21 subsection (a) may, in a civil action against the violator,
22 obtain appropriate relief. In a civil action under this section,
23 the court may award to the prevailing party a reasonable attor-
24 ney's fee and other litigation expenses.".
- --------Page 3
1 (b) CLERICAL AMENDMENT.- The table of sections at
2 the begining of chapter 65 of title 18, United States Code,
3 is amended by adding at the end the following:
"1368. Disseminating computer viruses and other harmful computer programs.".
- --------End of Bill
>>>>NOTE: The above text was typed in by hand from a printed copy of HR5061
>>>> received from Mr. Herger's office. I have no experience with
>>>> legal documents of this sort, and may have made typographical
>>>> errors which could affect the nature of the bill. Neither
>>>> I nor my employer (MIT Center for Space Research) make any claims
>>>> as to the accuracy of the text. For an official copy of the
>>>> bill, please contact:
>>>>
>>>> Mr. Doug Riggs
>>>> 1108 Longworth Bldg
>>>> Washington D.C. 20515
------------------------------
Date: Tue, 6 Dec 88 17:13:43 -0500 (EST)
From: Robert Steven Glickstein <bobg+@andrew.cmu.edu>
Subject: They did it: Speed-Thru Tollbooths
A news report last night on the Headline News Channel reported the experimental
installation of a new kind of tollbooth in Dallas, TX (I think?), and one or
two other places. Instead of tossing money into a hopper, you just drive on
through -- while a low-frequency, low-power radio signal polls an electronic
"tag" taped to your windshield, which (hopefully) squawks a valid code back at
it. (I was sort of amused to learn from the newscaster that this "tag" is made
from "printed circuits, capacitors and diodes.") Reportedly, toll plazas in
New York City and about a dozen other places will soon be outfitted with the
new technology.
The problems with this system from a RISKS perspective are numerous and
evident. Perhaps the most troubling is that the system works on an accounting
principle. Your "tag" uniquely identifies itself to the transmitter in the
tollbooth, and your passage is recorded. Presumably you then get a monthly
bill from the highway people. The problem here, of course, is that when you
drive through a tollbooth, Big Brother knows exactly where you are.
> *Excerpts from ext.in.risks: 18-Nov-88 Smart Roads (RISKS 7.81) Robert*
> *Brooks@sde.hp.com (1040)*
> Much concern has been expressed about the Big Brother potential of such
> systems. But this is by no means an essential hazard. The transponders,
> barcode tags, or whatever could be purchased anonymously, and authorization
> to cross various toll points n times purchased in advance, like postage
> stamps.
This would be fine, except that if the tags are completely indentity-free, then
stolen tags become especially problematic -- the thief is in no danger of the
tag becoming disabled, and the victim pays the thief's way through n tollbooth
passages, where n could be quite large (and quite expensive, especially in New
York, where tolls currently go as high as $3 for passenger cars). The
temptation to thieves to break into cars so equipped would therefore be very
great. In the current system, the tag is a non-descript black box secured
above the registration/inspection stickers by Velcro strips. Even if a car
owner were to hide the tag in the glove compartment when not in use, the Velcro
strips, permanently adhered to the windshield, are a dead giveaway.
The RISKS of theft are great even in the case of identifiable tags. The
non-descriptness of these black boxes makes it easy for a thief to replace a
stolen tag with a functionless dummy, so that it could be some time before the
victim even realizes the unit had been stolen, by which time the thief could
have run up quite a bill for the victim.
The greatest RISK posed by these units is that the subjects in the current
experiment seem to unanimously love the idea. Just breeze through a toll-plaza
-- great! It never occurs to the average technology-ignorant, computer-phobic
user that there may be some serious security/privacy problems here. I think
some sort of high-publicity demonstration of the flaws in this system are
called for as soon as possible.
Bob Glickstein, Information Technology Center, Carnegie Mellon University,
Pittsburgh, PA
------------------------------
Date: Sat, 3 Dec 88 22:42:07 EST
From: Brint Cooper <abc@BRL.MIL>
Subject: [Dave Nedde: Re: Toll Road information collection]
Dave Nedde quotes David Oster:
>>From: oster@dewey.soe.Berkeley.EDU (David Phillip Oster)
>>Is it fair to also stamp the tickets with the time of issue, so if the
>>distance traveled divided by the time elapsed is greater than the average
>>speed limit the toll taker can hand you a speeding ticket at the same time?
>>An appropriate computer would help the toll taker in this task.
Then he adds:
>Alas, as a Mass police officer pointed out in an interview, you have to catch
>someone *in the act* of speeding to get them for it. Probably something to do
>with that annoying bill of rights...
I seriously doubt that the Mass. police officer is absolutely correct. After
all, a favorite FBI strategy in catching professional hoodlums was to
prosecute, successfully on income tax evasion. The evidence often was nothing
more than a cash flow analysis: showing that someone spent more money in one
year than he reported as income! Convictions were upheld, no?
Risk of computers? Sure; think how often sucn analyses are possible
using computers: proving Medicaid fraud, failure to repay student
loans, catching scofflaws who replace a revoked driver's licence in one
state with a "good" one in another, etc.
Perhaps we should call this "benefits of computers?"
_Brint
------------------------------
Date: Mon, 5 Dec 88 09:48:28 CST
From: preece@xenurus.gould.com (Scott E. Preece)
Subject: Re: Toll Road information collection
From: Dave Nedde <daven@weathertop.prime.com>
> Alas, as a Mass police officer pointed out in an interview, you have to
> catch someone *in the act* of speeding to get them for it. Probably
> something to do with that annoying bill of rights...
I suspect it would be trivial to modify the law if it in fact prohibits such an
application now. The state has very broad discretion in controlling the use of
public roads and the privileges and responsibilities of those who hold state
licenses (they could make it a license requirement to report illegal traffic
behavior and then fine all licensed drivers in a car known to have been
speeding, if they chose to make the statutes work that way). I don't see any
way the Bill of Rights is even remotely involved.
scott preece, motorola urbana design center uucp: uunet!uiucuxc!mcdurb!preece
------------------------------
Date: Sun, 4 Dec 88 14:13:39 EST
From: sullivan@fine.Princeton.EDU
Subject: Re: Toll Road information collection
There was discussion of this in another newsgroup not too long ago. Someone
pointed out that exiting the toll road with average speed greater than the
speed limit does not prove you were driving over the speed limit, since you
might have switcherd drivers. Maybe this defense would indeed hold up--I no
lawyer--but I see no reason not to pass a new law to make exiting with too
little elapsed time a new crime. The owner of a car can be held responsible
for parking tickets even if someone else parked the car, so I see no reason
that whoever drives through the exit booth can't be held responsible for the
average speed.
John Sullivan
------------------------------
Date: Wed, 7 Dec 88 11:01:16 PST
From: Hibbert.pa@Xerox.COM
Subject: re: Subways that "know" who's on board
Regarding the item about the philadelphia subway system's capability to
track monthly pass-holders' movement:
I'm not particularly worried about this as an invasion of privacy, as long as
purchasers don't have to identify themselves when buying their passes. It
sounds to me as if the data they could collect doesn't contain any
identification of individuals. It doesn't seem problematic for the transit
commision to be able to gather statistics on individual traveller's routes, as
long as there's no ability to tie the information to who the traveller is.
I confess that I don't see a usefull way to correlate information on
different trips by the same individual. The most usefull information would
be just what the starting and stopping points were. Without this tracking
ability, they presumably can't tell what the distribution of trip lengths
is, and there are probably ways to make use of that information.
Oh, I guess there might be a privacy problem if there is real-time feedback
from the tracking system. For instance, if some police officer decides
that lots of short trips throughout the day (as an example) is
characteristic of some type of criminal of interest, it would be a problem
if there were a way to find out real-time that someone fitting that
description were right now passing through a particular turnstile.
Other than that possible hole, this seems like an example of a way to gather
data that starts out as a description only of average or sample behavior. As I
said, all this is wrong if users identify themselves when they buy their
passes.
Chris
[Well, many people pay by check or credit card, and that information would
of course have to be recorded, for bookkeeping reasons... PGN]
------------------------------
End of RISKS-FORUM Digest 7.91
************************
-------