RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (11/12/88)
RISKS-LIST: RISKS-FORUM Digest Friday 11 November 1988 Volume 7 : Issue 75
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Re: Risks of unchecked input in C programs (Bob Frankston)
NY Computer Laws and the Internet Worm (Dave Bozak)
Ethics (Stan Stahl, Christine Piatko)
Comments sought on proposed computer ethics course (Bob Barger)
UK vehicle-identification systems (Douglas Jones)
UK vehicle-id systems... Big Brother's new eyes? (Mike Hadjimichael)
Re: Phone-answerer/ voicemail security & voice-encryption (Jonathan Kamens)
Re: Ultrasonic emissions a real problem (Travis Lee Winfrey)
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 Nov 11 14:35:06 1988
From: bobf@lotus.UUCP
To: geoff@garp.UUCP
Subject: Re: Risks of unchecked input in C programs
The point about "gets" having no way to assure that the supplied buffer is
sufficient is a serious deficiency through the current ANSI(!) C library in
routines such as sprintfv and strcpy. This is a sloppiness that might be
justifiable in a hacking environment but is very dangerous and inexcusable for
production programs. I find it amazing that such interfaces persist into
product applications since what we have is an underspecified interface to
important system functions.
Of course, one could avoid using this part of the C library, but writing safe
code shouldn't be a matter of fighting the system, rather it should be an
expected use of the library.
Sorry if I seem so adamant about this but I've got to worry about supplying
complex software to millions of users who are quite inventive in novel ways to
(ab)use the software.
Bob Frankston
------------------------------
Date: Fri, 11 Nov 88 11:23:17 est
From: dab@oswego.Oswego.EDU (Dave Bozak)
Subject: NY Computer Laws and the Internet Worm
In regards to the recent Internet Worm, I am amazed that the
newspapers continually report that the FBI is not sure that any
laws were broken. In New York State, as of November 1, 1987, the
penal law was amended to include a new article, 156, titled
"Offenses Involving Computers". There are 2 relevant offenses.
Section 156.05: Unauthorized use of a computer. A person is
guilty of unauthorized use of a computer when he knowingly uses or
causes to be used a computer or computer service without authorization
and the computer utilized is equipped or programmed with any device
or coding system, a function of which is to prevent the unauthorized
use of said computer or computer system. Unauthorized us of a
computer is a class A misdemeanor.
Section 156.10: Computer trespass. A person is guilty of computer
trespass when he knowingly uses or causes to be used a computer or
computer service without authorization and: 1. he does so with
of any felony; or 2. he thereby knowingly gains access to computer
material. Computer trespass is a class E felony.
Clearly the design and release of a worm is a violation of
section 156.10. The worm was released was intended to gain access to
machines without authorization and was designed to gain access to
material (host lists) for propagation of the worm.
A felony is defined as an offense for which a sentence to a term
of imprisonment in excess of one year is authorized in the state.
Now maybe I am missing something here, not being a lawyer...so
would learned colleagues please clarify the legal issues involved
in this particular case?
------------------------------
Date: Fri, 11 Nov 88 00:51 EST
From: Stahl@DOCKMASTER.ARPA
Subject: Ethics
It's interesting that after the generally in-synch technical discussions
re RTM's virus, unanimity breaks down when the subject turns to ethics.
Christine Piatko, on the one hand, questions whether we can define
computer ethics in the absence even of agreement over house break-ins.
Jim Schweitzer, on the other hand, suggests that there ought not be any
question about proper computer ethics; that computer ethics is not
dissimilar to traffic rules.
I suggest that the situation is both less complicated than Piatko
suggests and more so than Schweitzer does. As for Piatko, I would hope
that as a society we agree that it is wrong to break into someone else's
home and, that whatever disagreement we might have, it is over the
punishment not the crime. Schweitzer, I believe, risks trivializing
significant ethical issues because, when all is said and done, traffic
rules have nothing to do with ethics but are agreed upon protocols for
sharing roadways.
The critical bottom line, and it is one that shouts out to us in the
wake of the RTM worm, is that we absolutely must begin to take the
teaching of ethics seriously. Some school districts are beginning to do
this and they are to be commended for it. Perhaps if everyone were
exposed to ethics courses, beginning in the early grades and continuing
through computer ethics courses and business ethics courses, etc, then
it would be clear `in the entire community what is and what isn't
ethical behavior.'
Stan Stahl
------------------------------
Date: Fri, 11 Nov 88 11:37:38 EST
From: piatko@svax.cs.cornell.edu (Christine Piatko)
Subject: Re: insecure passwords/computer ethics
I forgot about electronic snooping. I was mostly thinking of the 'common
password list' that was found with the virus. At least some of them were
actual passwords of people at Cornell that were common English words.
I didn't realize the Ethernet was wide open for such snooping. Maybe that
will happen next.
Christine
------------------------------
Date: Fri 11 Nov 1988 11:45 CDT
From: Bob Barger <CFRNB@ECNCDC.BITNET>
Subject: Comments sought on proposed computer ethics course
Eastern Illinois University has a two-semester-hour requirement for
senior year students of a seminar "organized around a particular
subject/issue important to contemporary society" which must be taken
in a field outside the student's major field of study. The following
is a seminar proposal on which comments/suggestions are sollicited:
COMPUTER ETHICS: This seminar will investigate current ethical
issues involving computers. There will be no class meetings, except
for the first and last sessions. Students will instead utilize
electronic bulletin boards on the university's mainframe computer
network to research and discuss issues.
Week: Topic:
1 Orientation to the course: initially, the seminar members
will meet as a group in a traditional class setting for
purposes of introduction, and explanation of course
content, ethical paradigms, class procedures, and
evaluation criteria.
2-14 Weekly on-line reading of such bulletin boards as
"Discussion of Ethics in Computing" (ETHICS L) and the
"Forum on Risks to the Public in Computers and Related
Systems" (RISKS), weekly posted reactions to these
readings, and posted comments on other students'
reactions.
15 Final examination and course evaluation: the seminar
members will reconvene as a group for the last meeting to
allow for individual examinations and group reflection on
the seminar experience.
Writing component:
Students will compose a weekly 30-to-50 line reaction to their
bulletin board readings. These reactions will be posted (i.e.,
sent to the mainframe computer bulletin board set aside for
members of this seminar). In their reaction, students will: 1)
identify the particular publication or publications to which
they are reacting, 2) identify the particular issue or issues
raised in the publication(s), 3) identify the ethical
implications of the issue or issues, 4) identify the ethical
paradigm on which the author seems to be depending, 5) add their
own reasons for agreement or disagreement with the viewpoint of
the publication's author, 6) and, finally, offer an alternative
solution or viewpoint to that presented by the author, or
present other appropriate considerations not raised by the
author or covered in their own previous comments under #5 above.
The instructor will send to the student, by electronic mail, a
weekly grade on the student's posted reaction, together with
whatever comments the instructor thinks helpful. The student's
original posted reaction will be open to public comment by the
other students in the seminar [this will be accomplished by
posting notes to the bulletin board, referencing the original
reaction]. These latter comments by the other students in the
seminar will form the basis for the "participation" factor of
the semester grade.
Evaluation: Each student's semester grade for the seminar will be
calculated according to the following weighted formula:
- 13 posted reactions (at 5% each) = 65%
- Participation (based on posted comments on
other students' reactions) = 20%
- Final Exam = 15%
Send comments to: Bob Barger<cfrnb@ecncdc.bitnet>.
Suggestions for texts in computer ethics are especially sollicited.
------------------------------
Date: Thu, 10 Nov 88 18:06:52 CST
From: Douglas Jones <jones@herky.cs.uiowa.edu>
Subject: UK vehicle-identification systems
In his 9 Nov 88 11:21:15 PST RISKS contribution, Chaz Heritage suggested that
the electronic number plates to be fitted on every vehicle were to be some kind
of IFF (Identification: Friend or Foe) device. This suggests an active
electronic transponder of some type. In fact, the technology needed for road
vehicle identification is much simpler, comparable to the automatic car
location technology used by the railroads. In the United States, we use a
black rectangle painted on the side of each railroad car, on which colored tape
has been fixed in a machine readable pattern. Bar code scanners located at the
track side can read these as the train moves. (aside: the bar code is read
vertically, so it remains readable independently of the direction of train
motion, and there is a wide latitude in the allowed positions of the code.)
The only problem with the US system is that the code has to be washed once in a
while or it gets grime covered and unreadable.
In the UK, I heard about 15 years ago that they were experimenting
with a microwave readable bar code for automatic car location.
This was readable through arbitrary accumulations of grime, and
was constructed of a metal channel with covers welded over the
channel to give a binary code. Something like this, mounted on
the underside of a car, would be quite practical for automatic
road vehicle identification, with sensors reading from below
as the car passes through the "toll station".
The risk of such sensors as police devices depends to a great extent on how
easy it is to instrument locations in the roadway without the driver being
aware of it. The grime-proof channel described above would be read from below,
and a car would have to pass directly over the reader, so it wouldn't work on
the open road, where cars could easily dodge the sensor. US style bar codes
are easily covered, but when exposed, can be read from an inconspicuous
roadside scanner. Aircraft style IFF devices would allow actual tracking of
cars from a distance without fixed scanners.
Douglas W. Jones, University of Iowa jones@herky.cs.uiowa.edu
------------------------------
Date: Fri, 11 Nov 88 19:20:08 EST
From: hadj@sbcs.sunysb.edu
Subject: UK vehicle-id systems... Big Brother's new eyes?
In RISKS 7.74 "chaz_heritage.WGC1RX"@Xerox.COM writes:
>Every vehicle in the country would have to be fitted with what is described
>as an 'electronic number-plate'. ...
>When the IFF-equipped vehicle is driven through a toll point, its IFF is
>interrogated by devices installed in the road surface. It then transmits,
>by some means, the vehicle's registration number to the interrogation
>devices. These communicate directly with the road owner's computer system.
>Clearly this computer system must either be connected to, or share a common
>database with, the Driver and Vehicle Licensing Centre at Swansea, which
>holds all records of registered vehicles. ...
>... There has,
>of course, been no suggestion that the interrogation devices might also be
>connected to the Police National Computer, since such a suggestion would be
>either what the Government call 'irresponsible journalism' (if it were not
>demonstrably true) or a breach of the Official Secrets Acts (if it were). ...
>It would, of course, have to be made a crime to drive without an IFF
>device, or with a faulty one (how one is supposed to establish that one's
>IFF is working correctly - when its principle of operation is apparently a
>secret - is not clear).
I find this to be a terrifying bit of news, based on the fact that a
government will always use the information it can get access to, if
necessary...(if a court can get access to a reporter's notes, why not
a road owner's database?)
Possible uses:
1) the use of such travel information in a case against a suspected
criminal:
Lawyer: "Where were you on the night of Nov 8, 1988?"
Defendant:"I was sitting at home watching TV."
Lawyer: "Not true! Your car was observed passing toll
FOO on interstate BAR!"
2) the use of such information to find lawbreakers:
A trivial example: such information could be used to catch people
speeding on the highway. Attach a timestamp to each event and
calculate v = dx/dt.
There is, of course, nothing wrong with catching criminals. However,
the described system depends on privately owned computers and
various unreliable components (transmitters, etc) which are not
impervious to accidental or deliberate tampering. It seems easy
enough to fake evidence of this sort. Even if we assume the database
is 100% secure, the data collected could be corrupted. It seems
unlikely that the IFF boxes will be immune to reverse engineering.
Imagine a box that sends out a random ID signal every time it passes
though a toll point.
It is troublesome to think that somewhere, in some computer
database, there is a record of where and when some computer _thinks_
that i was detected driving my car.
The potential for invasion of privacy is enormous, and made more
frightening by the fallibility of the system. It is a powerful
system based on an insecure database. It would give Big Brother
one more set of eyes on the world.
-mike hadjimichael.
{ hadj@sbcs.sunysb.edu {philabs, allegra}!sbcs!hadj }
{ departmentofcomputersciencesunystonybrookstonybrooknyoneonesevenninefour }
------------------------------
Date: Thu, 10 Nov 88 18:05:11 EST
From: <jik@ATHENA.MIT.EDU>
Subject: Re: Phone-answerer/ voicemail security & voice-encryption
Date: Wed, 09 Nov 88 13:42:33 -0800
From: "David A. Honig" <honig@bonnie.ICS.UCI.EDU>
Unauthorized phone-answering-machine playback and unauthorized
centralized-voicemail message playback could be made more difficult
by encrypting the stored messages. This could be done at the same
time as data compression preprocessing on digital systems. (There
are analog "encryption" methods but these days everything's cheaper
digitally...)
Yes, but the whole point is that the answering machines currently on the market
provide minimal message security because the access codes are so ridiculously
simple to "crack" (I place "crack" in quotes because I'm not sure the task is
difficult enough to call it "cracking."). In order for encrypted-data
answering machines to allow remote message access, they would expect you to
enter the decryption key over the phone line. If the decryption key is complex
enough that it cannot be guessed (which is really the question is being asked
here), then why use encryption at all? Just use that key as the password, and
security is assured (as much as it can be, at least).
In other words, I fail to see how data encryption provides an increased measure
of security in the context of the problem we are discussing, which is the lack
of a secure password.
Jonathan Kamens, Massachusetts Institute of Technology -- Project Athena
------------------------------
Date: Fri, 11 Nov 88 15:36:34 EST
From: travis@douglass.cs.columbia.edu (Travis Lee Winfrey)
Subject: Re: Ultrasonic emissions a real problem
>Date: Mon, 07 Nov 88 18:13:29 EST
>From: Geoffrey Welsh <izot@f171.n221.z1.fidonet.org>
>Subject: Ultrasonic emissions a real problem
> What, then, leads some of us to be sensitive to these frequencies to a
>fault and others to be completely unaware of them? Worse, how can we determine
>what levels are acceptable, given that some people are simply more sensitive
>than others?
Although I don't know why, asthmatics are known to hear very high sound
frequencies, well over 22 KHz. I've been able to hear terminals, TVs, dog
whistles since I was very young. Brand X CRT's and Kaypro's have made me
clap my hands to my ears.
> If indeed ultrasonic emissions are a cause of illness or other unacceptable
>consequences, it is vital that a study into the area be launched. Who knows;
>in a few years we may find our present CRTs replaced with ones that have a
>horizontal scan rate above 30 KHz to avoid this problem.
It was explained to me once. There is a common component in RGB CRT's
which alternates very rapidly, around 26-28 KHz. Particularly in older
TV's, this component takes a while to cycle up, which is why when someone
turns on a TV in the next apartment (or building!), I can hear the
high-pitched sound it makes begin loudly then almost disappear.
I personally would worry more about vision, back, and stress problems
caused by introducing computers into the workplace. The high-pitched
sounds falls more into the category of Stupid People Tricks.
------------------------------
End of RISKS-FORUM Digest 7.75
************************
-------