The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 16 Issue 63

Friday 9 December 1994

Contents

o "High-Tech Can Hinder Policy Work"
PGN
o Laptop proscription
Bob Morris
o Our police and media in action [RF interference]
Lynn Gold
o Digital cash on the web -- comments?
Justin Wells
o New printer font: Sloppy Handwriting 14pt
Norman H. Cohen
o Multicast backbone blunder [risks of hidden transmission]
Alan Clegg
o A Question for the Community regarding National Crypto Policy
Herb Lin
o Problems with compiler optimisation (Pentium related)
Martin Poole
o Risk of _not_ using floating point.....
David Lesher
o Re: Formal methods and the Pentium FDIV
Tim Bradshaw
o It's all my fault, really [re: Good Times]
Martin Minow
o Good Times is a *meta*virus
Joe Chew
o Good Times is a Meme
Keith Henson
o Re: Schneier's book "Applied Cryptography"
Y. Radai
o Re: Fun with your phone company
Geoff Kuenning
Russell Stewart
o More on network file race condition
Andrew Koenig
o Rights and Responsibilities of Participants in Networked Communities
Herb Lin
o Searching RISKS et al.
Frederick B. Cohen
o Info on RISKS (comp.risks)

"High-Tech Can Hinder Policy Work"

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 9 Dec 94 10:15:03 PST
The Supreme Court is divided over a case involving false arrest due to
erroneous computer data, attributed to human error.  Ruth Bader Ginsburg
was quoted thusly: ``As automation increasingly invades modern life,
the potential for Orwellian mischief grows.''  Antonin Scalia countered
that nothing is gained by excluding evidence of true wrongdoing because
some subordinate did not purge outdated information from a computer system.

The case arose after Isaac Evans was stopped in 1991 in Phoenix for a minor
traffic violation; he was arrested because of a hit identifying an
outstanding warrant --- although though that warrant had been previously
``quashed'' and should have been removed from the database.  Furthermore,
the arresting officer then detected the presence of marijuana.  The Court is
reviewing whether, under the circumstances, that evidence can be used in a
trial for drug possession in light of the false arrest.

[Source: A Washington Post item appearing in the San Francisco Chronicle,
8 Dec 1994]


Laptop proscription

<RMorris@DOCKMASTER.NCSC.MIL>
Thu, 8 Dec 94 20:42 EST
Act 4 of Shakespeare's 'Julius Caesar' opens with Mark Antony, Octavius,
and Lepidus meeting to work out the proscription that is to follow
Caesar's murder.  To be proscribed means that you are rubbed out and
your property confiscated by the people doing the proscribing.  Clearly,
proscription is a significant data processing problem since both the
rubbing out and the division of spoils have to be worked out to the
satisfaction of the proscribers.

In a recent production of Julius Caesar by the Folger Shakespeare Theater in
Washington, D.C., there was only a modest amount of tittering when one of
the proscribers arrived on stage to do the necessary work with a laptop.

Bob Morris

    [I presume the character was ProScribe rather than ProLaTeX?
    Was Folger in his Cups? or Caps?
        (Sorry.  That multipun is only for OLD Washington logicians.)  PGN]

       [Marc Rotenberg added, out of band, i.e., not in RISKS-16.63 as mailed:
          If Caesar lived until proscribed at the Folger,
          he was obviously good to the last drop.]


Our police and media in action

Lynn Gold <figmo@netcom.com>
Wed, 7 Dec 1994 22:46:34 -0800
I got the following from ba.broadcast today and felt it was worth sharing
here....

The following is an INEXACT quote from KCBS, one of our all-news radio
stations:

  ...the police have called the bomb squad to defuse the hand grenades. Until
  the grenades are defused, the police have prohibited the use of 2-way radios
  in the vicinity of the scene here, so we are reporting by cellular phone
  instead of radio.

Somebody needs to tell the folks at KCBS the meaning of "radio."

Somebody also needs to give the police a clue.

--Lynn


Digital cash on the web -- comments?

justin wells <rjwells@undergrad.math.uwaterloo.ca>
Wed, 7 Dec 1994 23:13:14 -0500
There are a lot of people over in the comp.infosystems.www.* newsgroups
who are seriously talking about using the World Wide Web (WWW) as a
digital cash system.  I get the impression they want to do this in some
number of months or a year.

Apparently they want to use the FORMS feature supported by most web browsers
in conjunction with some sort of encryption algorithm.  The idea is you
connect to a commercial site, see see something you want to pay for, fill
your credit card number in on the form, and transmit it back to the http
server with some kind of encryption.  They're talking about using some
encryption technique present or expected in the Netscape browser.

As far as I can tell this method will not involve any sort of
authentication, and it will only secure data after it has left your browser
and before it gets decrypted.

Are these people for real?  This has to be one of the most foolish things
I've heard in a long time, but I'd like to hear some comments from RISKS
readers -- I'm no expert in these matters.  It might also be an idea to
crosspost a bit of the discussion back to *.www.* to wake these folks up.

Justin Wells  rjwells@uwaterloo.ca


New printer font: Sloppy Handwriting 14pt

"Norman H. Cohen" <ncohen@watson.ibm.com>
Fri, 9 Dec 94 09:43:21 EST
I received an envelope in the mail yesterday that was immediately
identifiable as junk mail by the word "URGENT" printed in large red
letters imitative of a rubber stamp.  Thus I was taken aback that the
envelope appeared to be hand-addressed with a felt-tip pen.

Closer examination revealed that the apparently sloppily scrawled capital
N in my first name was identical to that in "NY", the even sloppier
lower-case A in my first name was identical to those in my street name
and city name, and so forth.  Nonetheless, to the casual observer, the
effect was quite convincing.

The risk is an old one--the use of computers to perpetrate a deception.


Multicast backbone blunder [risks of hidden transmission]

Alan Clegg <abc@black-ice.gateway.com>
Thu, 8 Dec 1994 13:14:57 -0500 (EST)
While watching the multicast of the current IETF session [Automatic
Address Configuration], I was presented with a message imposed by the
broadcasting group of "susanp@spinnaker please stop broadcasting".

I looked at the monitor, and sure enough, there was *another* video session
being broadcast.  For the next ~5 minutes, everyone on the multicast
backbone was allowed to watch as susanp worked on some html markup [using
hotmetal], then responded to a bit of e-mail.

The risk turns out to be that the newest version of the NV video
transmission software allows you to transmit video across the mbone
without a camera... any window or cursor-followed region will be happily
transmitted to the world... It is not obvious in ANY way that you are
actually transmitting any information...

I called the person listed in the WHOIS database for the address range
that Susanp was in and the session went away, BUT... what would have
happened if susanp had started doing something that was more company
confidential?  Since folks are recording the multicast digitally, all it
would take is one screen shot with private information..

- -abc


A Question for the Community regarding National Crypto Policy

<CRYPTO@nas.edu>
Fri, 09 Dec 94 10:30:00 EST
As many of you know, the National Research Council is undertaking a study of
national cryptography policy (description available on request to
CRYPTO@NAS.EDU).  This note is the first of a number of questions that will
be posted to the Internet community in our attempt to solicit input on a
broad scale.  Please circulate this request to anyone that you think might
be able to contribute.

The question of this posting is the following:

How, if at all, do capabilities enabled by new and emerging technology in
telecommunications (e.g., key-escrow encryption technologies, digital
telephony) and electronic networking make it _easier_ for those who control
that technology to compromise and/or protect the interests of individual end
users?  Please use as the standard of comparison the ease _today_ of
compromising or protecting these interests.  We are interested in scenarios
in which these interests might be compromised or protected both individually
and on a large scale.  Please be sure to tell us the interests you believe
are at stake.

Please send your comments on this question to CRYPTO@NAS.EDU.


Problems with compiler optimisation (Pentium related)

<mpoole@heac006.gb.ec.ps.net>
Wed, 7 Dec 1994 11:59:51 +0000 (GMT)
You may amused/horrified to hear of an incident that occurred at a
major city bank last week here in the UK.

On hearing of the Pentium bug, they decided to test all of their machines to
see which had the problem. They compiled up a test program and checked all
of their Pentium based machines and discovered that all of them had the fdiv
bug. They decided to be extra cautious and run the same program on all the
other machines. To their horror all of the 486 machines exhibited the same
problem.

After several days of headless chicken impersonations, a more-level head
decided that something must be awry and called in a good friend of mine who
in short order discovered their mistake.

The test program was compiled on a Pentium box and had the sum performed
with constants. The compiler had noticed the use of constants and had
performed the sum there and then, putting the result in the executable
to be printed on demand on whichever box it was run on.

The risks involved are obvious but the solution is less so. Even if
the sum is done using variables, what is to stop the compiler from
noticing that the values do not change between initialisation and
the time of performing the calculation, and cause the same problem ?
(Yes, I know. Use functions, pass parameters. But what if it gets
in-lined, and then optimised ?)

Admittedly this only normally occurs on binaries that are shipped for
alternative platforms, but how many software houses use the smaller chips
(386/486) as the main compile engine before shipping ?  And of course, users
who have Pentiums without the bug, but use software compiled by a chip with
it are also susceptible.

The effects and problems of this are going to be with us for a long time.

Martin Poole, Perot Systems Europe
mpoole@heac006.gb.ec.ps.net   mpoole@cix.compulink.co.uk


Risk of _not_ using floating point.....

David Lesher <wb8foz@netcom.com>
Fri, 9 Dec 1994 10:38:27 -0500 (EST)
I spent 3 hours holding in the queue for XXX tech support before I got to
speak to a person. When I did, I mentioned my wait. He apologized for the
delay, then observed that his 'hold-time' counter had overflowed at 99
minutes.....

Such invalid data should do wonders for their staffing projections.


Re: Formal methods and the Pentium FDIV (Stalzer, RISKS-16.62)

Tim Bradshaw <tfb@edinburgh.ac.uk>
Fri, 9 Dec 94 00:57:01 GMT
> Many formal approaches would not have caught this kind of error  ...

I haven't followed all the arguments about random testing, but it's also the
case that random testing is not appropriate for this sort of problem. If you
have something like a lookup table in there, it really does make sense to
make sure that you test *all* the entries in that table: trying to do this
with random numbers is crazy.  As to trusting it because it was generated by
computer: well, I wouldn't trust *anything* that was easy to check if I was
about to make millions of dollars worth of it.

--tim


It's all my fault, really [re: Good Times]

Martin Minow <minow@apple.com>
Thu, 8 Dec 1994 08:04:59 -0800
You may have received a few messages recently regarding a supposed computer
virus spread through the mail. Unfortunately, it's nothing new -- in fact,
it was announced in a RISKS submission not too long ago. With the kind help
of the RISKS moderator (no doubt, digging out from under his own avalanche
of reports), I am enclosing it for your consideration.

Martin Minow  minow@apple.com (note new address)

  RISKS-LIST: RISKS-FORUM Digest   Friday 1 April 1988   Volume 6 : Issue 53

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
[...]
Date: 1 Apr 88 00:00
From: minow%thundr.DEC@decwrl.dec.com
      (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922)
Subject: Virus attacks RISKS

Today, I'm afraid I must confess that one of my recent postings to RISKS
contained a Virus that Peter (no doubt inadvertently) distributed to the
RISKS audience.  The virus doesn't infect your programs or data files
directly, but in a manner analogous to the "Christmas card" virus discussed
here a few months ago, it causes increased network traffic.

As the virus establishes itself, you will note its affect by the increased
amount of electronic mail you receive every day.  For some of you, the
increase is linear; but for others, I'm afraid you're on the early part of a
exponential curve.

Although the virus was easy to create, I'm afraid that I don't know how to cure
it.  In fact, I believe I'm beginning to note its effects on my own system.

Humbly, Martin Minow

  [PS: No avoid another visit from corporate security, please take careful
         note of the date of the original submission.]
  [PPS: No, I didn't hack the mail protocol to get that date: I just stayed
        up late that evening.]


Good Times is a *meta*virus (RISKS-16.62)

Ad absurdum per aspera <JTCHEW@lbl.gov>
Wed, 07 Dec 1994 16:54:35 -0800
Naah -- "Good Times" is the first *meta*virus.  The target is available
bandwidth itself; it acts by getting well-meaning users to send virus
warnings to huge, massively overlapping mailing lists. :)

Joe "Dyn-o-mite!" Chew


Good Times is a Meme (Keith Henson)

<hkhenson@cup.portal.com>
Thu, 8 Dec 94 11:26:38 PST
In RISKS 16.62 Zygo Blaxell (zblaxell@miranda.uwaterloo.ca) and Reuven
Lerner <reuven@hpwadck.wal.hp.com> both make good points re the "Good Times"
'virus' where the message about a virus it *itself* a virus!  (With possibly
bad long term effects.)  Computer viruses & human fads (like passing on the
Good Times warning) both fit the model of a meme.  (See _Selfish Gene_ by
Richard Dawkins.)  A meme is one type of *replicating information pattern*,
genes are the other main class.  Putting a class name such as "meme" on Good
Times helps us group things/events into classes where we can expect
analogous effects.

What computers and fast communications have done is to radically change the
replication constants for memes, and to make unworkable the controls society
has tried to put on such things.

Keith Henson (whose articles on memes are widely available on the net.)

    [Re: Joe Chew's previous item:  *Meme chose?*  PGN]


Re: Rob Slade's review of Schneier's book "Applied Cryptography"

Y. Radai <RADAI@vms.huji.ac.il>
Thu, 8 Dec 94 14:32 +0200
> ... the book contains a substantial number of typos ...

This is all too correct.  I should like, however, to add three points:
  (1) The book contains not only many typos, but also a number of serious
errors in its descriptions of some of the algorithms.  (I pointed out
several of these last June; copies of my posting are available from me by
e-mail.)
  (2) While Schneier himself maintains a cumulative errata sheet, the
publisher (Wiley) apparently refuses to include it with copies of the
book which have been distributed since the appearance of the errata sheet.
  (3) The good news is that Schneier is preparing a second edition, which
will, of course, correct all known errors.  It will also contain several
new sections not present in the first edition.

   Y. Radai,  Hebrew Univ. of Jerusalem, Israel,  RADAI@VMS.HUJI.AC.IL


Re: Fun with your phone company (Stewart, RISKS-16.61?)

Geoff Kuenning <geoff@FICUS.CS.UCLA.EDU>
Wed, 7 Dec 94 17:47:36 -0800
As one who worked on bill-payment ("remittance processing") systems many
years ago, I find this conclusion [take the phone number off the check, not
the stub] highly implausible, to put it mildly.  A phone, utility, or
credit-card company in a moderately large city must process literally
hundreds of thousands of payments every day (divide the phone population by
30).  The return portion of the bill is carefully encoded with many things,
including both the account number and the amount due.  That way, when the
human operator types in the amount of the check, it is assumed correct if it
matches the amount due, saving a costly verification step.  Since the bill
stub *has* to be OCR'ed, why would anyone build a complex and expensive
system to scan the check for a phone number, printed in an unknown location
in an arbitrary typeface (if it's present at all) instead?

It is far more likely that Russell accidentally sent in the wrong half of
the stub, or no stub at all, and a human somewhere was faced with trying to
credit the proper account with his payment.  Since the phone number was on
the check, the human assumed it represented the proper account -- an
unjustifiable assumption, but an understandable one when you consider that
there are thousands of these errors to deal with every day, so that it's not
practical to make a phone call to verify the assumption, and the customer
would probably get very upset if you mailed the check back without cashing
it.

The RISK here is not a computer risk, but simply that it is always
unfortunate to fall through the cracks of a system that is too big to
give individualized service.

    Geoff Kuenning  g.kuenning@ieee.org geoff@ITcorp.com


Re: Fun with your phone company (Kuenning, RISKS-16.63)

Russell Stewart <diamond@RT66.com>
Wed, 7 Dec 94 21:06:35 MST
>As one who worked on bill-payment ("remittance processing" systems many
>years ago, I find this conclusion highly implausible, to put it mildly.

So would I! But I am only repeating to you what the woman at the phone
company told me; and my $150 *was* credited to my dad.

Actually, on further reflection, I've come to the conclusion that it
probably *wasn't* an automatic scanner, but a human being. I suppose
that sort of invalidates this as a Technological RISK.

>It is far more likely that Russell accidentally sent in the wrong half
>of the stub, or no stub at all, and a human somewhere was faced with
>trying to credit the proper account with his payment.

No, I sent in the correct portion of the bill, as I always do. Believe
me, if you'd had the experiences I've had with the local US West office,
you wouldn't be so skeptical.

Russell Stewart   Albuquerque, New Mexico  diamond@rt66.com


More on network file race condition (RISKS-16.62)

<ark@research.att.com>
Thu, 8 Dec 94 13:40:35 EST
Several people have suggested to me, some rather haughtily, that my
corrupted /etc/hosts file would not have come about had I been using an
operating system that supported file locking by default--that is, if only
one process could have a file open for writing at a time.

Looking over the code to see if this was true revealed Cause 4.  It turns
out that the file is built up in several phases:

    1. Generate the entries for `localhost' and `loghost'
       in a temporary file.

    2. Append the entries for machines I am likely to use often
       to the temporary file.

    3. Append all the other entries to the temporary file.

Because this is done as a shell script, each phase opens the file,
appends to it, and then closes it.  That means that file locking
would not have avoided the race condition.

One person suggested to me that I should have built /etc/hosts in
a temporary file rather than immediately overwriting the good copy.
In fact, I did just that.  However, since I `knew' that the program
would never run more than once at a time, I used a fixed name for the
temporary file.  Since that name was in my home directory, each process
on each machine used the same file.

Finally, I will note that I know how to make the program safe against
multiple accesses, even without file locking: use a separate temporary file
for each invocation and then, instead of copying the file to its final
place, move it there atomically.  I don't know how to make such things
automatic, though, and it's far from clear that one should always take such
precautions, even for programs one believes will be run only on one's own
behalf.
    --Andrew Koenig  ark@research.att.com


Rights and Responsibilities of Participants in Networked Communities

"Herb Lin" <hlin@nas.edu>
Fri, 09 Dec 94 10:27:00 EST
The Computer Science and Telecommunications Board (CSTB) is pleased to
announce the availability of a new report entitled _Rights and
Responsibilities of Participants in Networked Communities_.  Given
increasing public interest and concern over the behavior of people on
electronic networks, the report seeks to illuminate, to question, and to
articulate difficult issues that arise in this context, and thus to help to
lay a foundation for a more informed public debate and discussion of the
rights and responsibilities of those who operate in this domain.

The report is based on a workshop and a public forum involving
technologists, lawyers, policy analysts, network service providers, and
network operators in the exploration of several hypothetical but plausible
scenarios in four areas (free speech, electronic vandalism, intellectual
property interests, and privacy).  The report illustrates how disagreements
in these areas are rooted in value judgments; for example, the extent to
which continuity with past precedents is desirable.  Lawyers and
policy-makers often argue that rights and responsibilities in a new domain
inherently derive from existing rules, the report says.  By contrast,
technologists with extensive network experience often assert that with a new
medium and a new form of human expression should also come new rules of
social intercourse.  The report notes that these four areas have always been
inherently contentious, but over time certain compromises and understandings
have evolved that guide what people do when communicating via traditional
media such as print, telephone, radio, and television.  Today the
proliferation of networking technology threatens this state of understanding
because it changes the environment in which previous compromises were
achieved, leading to a re-examination of the same fundamental issues.

The report is available from the National Academy Press for $25.00 (prepaid)
plus $4.00 shipping for the first copy and $.50 shipping for each additional
copy; tel. (202) 334-3313 or 1-800-624-6242.  It will also be available soon
on the WorldWide Web at http://www.nas.edu; via Gopher at gopher.nas.edu;
and via FTP at ftp.nas.edu.

The National Research Council is the principal operating arm of the National
Academy of Sciences and the National Academy of Engineering.  It is a
private, non-profit institution that provides independent advice on science
and technology issues under a congressional charter.  CSTB addresses
national scientific and policy issues in computing science,
telecommunications, and computer technology and their applications.


Searching RISKS et al.

"Dr. Frederick B. Cohen" <fc@all.net>
Fri, 9 Dec 1994 07:16:40 -0500 (EST)
    I have recently setup a Mosaic server with on-line copies of the
RISKS Digest and other on-line material on similar topics.  This server
allows the user to search full text for any given word, and produces a
listing of all occurrences (in context).  The user then selects the
desired item(s) and views the files they occur in.

    I am writing to RISKS for 2 reasons.  One is to ask permission
to use the Risks Forum in this way (after all, it is copyrighted as of
its creation), and the other is to inform your readers of the proper
URL (http://all.net:8080).

    Please don't search for anything like "and".  You will find that
the search produces a LOT of useless results.

FC

   [FRED: Many thanks for doing this!  I'll add it to the Info.
   Yes, you have my permission.  But I trust that your home page will
   request users to respect any copyrights (explicit or implicit) and
   fair-reuse practices.  Also, suggest that folks should remember to
   scan for subsequent corrections...  PGN]

Please report problems with the web pages to the maintainer

Top