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 89

Friday 10 March 1995

Contents

Celsius-to-Fahrenheit conversion risk

Michael Tobis

Two on net porn charges

Jonathan Bowen

Re: 6-cent T-shirts

Evelyn C. Leeper

Re: Remote-Control Risks

Mike Cavanagh

Consumer electronic problems

Les Hatton

Can Pakistan Eavesdrop in America?

Peter Wayner

Sow's Ear from a Purse

Joseph H Presley

Resetting BSD/OS is easy as resetting MS-DOS (Re: Sparc10)

Kenji Rikitake

Re: Microsoft and Lotus spreadsheet errors

Tony Lauck

Loss of one of the X-31 research airplanes

Peter Ladkin

PGP Moose: moderator authentication and antispamming tools

Greg Rose

Info on RISKS (comp.risks)

Celsius-to-Fahrenheit conversion risk

Michael Tobis <tobis@skool.ssec.wisc.edu>

Wed, 8 Mar 95 18:15:15 CST

I thought the RISKS readership shouldn't miss this gem, posted in
sci.geo.meteorology by stevenb@pauli.jhuapl.edu (Steven Babin at Johns
Hopkins University Applied Physics Laboratory):

> There seems to be some confusion over the giant iceberg.  [...]
> The Reuters news agency reported that the iceberg was 656 feet 2
> inches thick, implying a tremendous accuracy of measurement.  It
> is actually 200 m thick and the reporter converted this to English
> units.  Reuters also reported that this event was the result of a
> 36.5 F increase in temperature since the 1940's.  It was actually
> a 2.5 C increase.  The reporter apparently converted this to F
> as a temperature rather than a temperature difference.
> I don't know whether this speaks more for the educational level of
> reporters or more for the fact we should all be using SI units.

The risks of the transmission of technical information by people who don't
know what they are talking about will be familiar to RISKS readers.  Perhaps
more striking is the risk that something as simple as a Celsius to
Fahrenheit conversion algorithm can be misused by making invalid assumptions
about context.

Michael Tobis  tobis@skool.ssec.wisc.edu

   [And the mention of SI reminds me of Steve Lipner's OLD joke about
   being an SI, namely a Civil Engineer.  (For those of you who don't
   get it, sivil injinears are not supposed to be able to spell.)  PGN]

Two on net porn charges

<Jonathan.Bowen@comlab.oxford.ac.uk>

Fri, 10 Mar 95 13:13:31 GMT

Newspaper: The Times Higher Education Supplement
URL: http://www.timeshigher.newsint.co.uk/
Reference: page ii, Multimedia news section, 10 March 1995
Headline: Two on net porn charges

An 11-month investigation by West Midlands police has led to two men being
charged with distributing child pornography on the Internet.  The charges
arise from a raid by police on the metallurgy department at Birmingham
University following information on child pornography passed to them by
federal authorities in the United States.  ...  The prosecution is seen as
[a] test case on what can be legally transmitted globally across the network
from computer hosts.

Jonathan Bowen, Oxford University Computing Laboratory, Programming Research
Group, Wolfson Building, Parks Road, Oxford OX1 3QD, England.

Re: 6-cent T-shirts

Evelyn C. Leeper <ecl@mtgp003.mt.att.com>

Thu, 9 Mar 1995 19:50:44 GMT

> we end up with .06 cent t-shirts and free shallots.
                 XXXXXXXX

This is a pet peeve of my husband's (and by extension, of mine, I suppose).
He keeps trying to explain to the clerks why they should sell him that
two-liter bottle of Coke for a cent, when the sign says, ".99c" ("c"
actually being a cents-sign).

The Risks in this?  I suppose it's the risk that if people have turned over
all their computing to machines and don't even *think* about where the
decimal point should go, then we're all in trouble.

Evelyn C. Leeper | +1 908 957 2070 | Evelyn.Leeper@att.com

Re: Remote-Control Risks

mike <mike@emgee.demon.co.uk>

Thu, 9 Mar 1995 02:18:41 +0100 (GMT)

I was interested to see the examples of optical remote-control systems being
upset by other light sources.  In my student days I worked as a TV engineer
in holidays.  A customer complained that his set would randomly switch
channels.  Several weeks of to-ing and fro-ing to the workshop failed to
find a problem.  Eventually the cause was found.  The customer kept budgies
in an aviary outside the window next to the TV.  The set had an ultrasonic
remote control.  The budgies were setting off the remote.  If you made the
budgies tweet, the set changed its channel.

These risks are still there 20 years later.

Mike Cavanagh

    [A new Hallowe'en motto: Click or tweet?
    With the new noise-cancellation techniques,
    the challenge is how to balance the budgies.  PGN]

Consumer electronic problems

Les Hatton <les_hatton@prqa.co.uk>

10 Mar 1995 11:44:38 +0000

Has anybody heard of consumer electronic stuff being recalled because of
software problems yet?  The reason I ask is that most such products will
have massive amounts of software in them by the end of the decade, (many
tens of thousands of lines in such things as televisions, cars, washing
machines, electric razors and so on).

As an example:

In August'94 I rented a Vauxhall Omega car for 1 month.  This car was brand
new and consequently has a number of micro-processor controlled systems.

In the first week, the sun-roof started to oscillate (in the rain!).  The
sun-roof is a simple rotating switch which you turn to the position you want
the roof and then leave it to move there.  Mildly concerned and alternately
dampened by this, my eldest son figured out that by pushing the button, the
roof reset.  On looking through the manual, in tiny writing at the back,
this featurette was described, "in case of some circumstances when the
sun-roof ...".

One week later, I discovered one morning that the car was completely without
power - not even the control panel lights came on.  A volt-meter revealed
that the battery was perfectly OK.  A call to the RAC (Royal Automobile
Club, a UK organisation that operates a rescue service like the US. AAA),
brought an engineer out who said it was one of two things, one of which he
could fix.  He moved the drive lever from Park to Drive and back and all the
lights came on and the engine would then start.  (The drive train is also
controlled by a microprocessor in this car).  I asked him what was the one
he couldn't fix.  He said that on this model, the auto immobiliser (the cute
little button on the key ring) could in some circumstances at the edge of
its range so immobilise the car that only the factory could get it going,
(the ultimate theft deterrent!).  I suspect that this is also controlled by
a microprocessor.  In fact on this car, the radio is controlled by two
microprocessors !

In terms of reliability growth modelling, one person experiencing two
defects and hearing of another in just one month in one car adds up to a
shaky reliability record.

Hence my question at the beginning.  Maybe its just me, because I'm in the
profession.

Les Hatton, Ph.D. C.Eng, Director of Research & Engineering, Programming
Research Ltd, England   les_hatton@prqa.co.uk   +44 (0) 1 932 888 080

Can Pakistan Eavesdrop in America?

Peter Wayner <pcw@access.digex.com>

Thu, 9 Mar 1995 14:44:35 -0500

RISKS-16.88 includes a transcript of a Voice of America broadcast describing
Pakistan's hardball play to get access to Motorola's best cellular
eavesdropping technology. The transcript says that Pakistan shut down
Motorola's cellular service until it got the device that would let them
eavesdrop on all conversations.

I'm not sure if Motorola complied, but I hope that someone asked these
questions:

1) Can this eavesdropping hardware work in the United States? Many speculate
that Pakistan wants to be (or is) a member of the nuclear club of nations.
When a Princeton undergraduate designed a nuclear bomb for credit, he was
visited by someone who seemed to be a Pakistani intelligence operative. The
goal? Nuclear information.

2) Can this eavesdropping hardware work against Motorola? Industrial
espionage is a popular way for countries to do "research." Does Pakistan
want to build up a local electronics company?

3) Can this eavesdropping hardware be used against US companies angling for
business in Pakistan?

4) Will the technology make its way into the hands of the terrorists?
Several days ago, US citizens were killed in an ambush. The dead included at
least one intelligence operative. Today's Washington Post says that some
witnesses claimed a police car with a submachine gun mounted on the top
stood by idling and let the killers get away. The excuse is that they were
afraid. The ambush was supposedly retaliation for the US capture of
terrorists.

Years ago, we only needed to worry about whether we could trust our
immediate neighbors and the other folks in town. Now trust is a global game.

Sow's Ear from a Purse (Tepper, RISKS-16.88)

Joseph H Presley <presley@whserva.wh.att.com>

Fri, 10 Mar 95 10:39:21 EST

A zealous and unscrupulous prosecutor could "prove" that the KJV (King James
Bible) is obscene by using a mask of A=[KJV xor obscene].  [A xor KJV] gets
you the obscene file. Can you imagine trying to prove that you didn't just
erase your encryption mask to a technologically naive jury?

I should also mention that you could transmit A as your file and your
recipient use KJV as the encryption mask.

    Joe Presley

Resetting BSD/OS is easy as resetting MS-DOS (Re: Sparc10 keyboards)

Kenji Rikitake <kenji@reseau.toyonaka.osaka.jp>

Fri, 10 Mar 1995 13:17:25 +0900

The Sparc10 story reminds me of my 486 PC running BSD/OS; it was configured to
ask for rebooting if you press CTRL+Alt+Delete as default. I immediately
disabled this feature. I even consider this a bug, although you can fix it
by recompiling the kernel.

Think about this. Most MS-DOS users know CTRL+Alt+Delete, and many
of them just do it if they think they have done something wrong with their
PCs. And few of them know the difference between MS-DOS and BSD/OS; what if
they start to use BSD/OS? Rebooting everytime they think they've got crashed?

BSD/OS has another design flaw on its X server. You can terminate it anytime
by pressing CTRL+Alt+Backspace. This is enabled as default, though you can
turn this off by its configuration file. I respect flexibility of UNIX, but
it's obviously dangerous to enable emergency-stop features to everybody.

// Kenji Rikitake <kenji@reseau.toyonaka.osaka.jp>

Re: Microsoft and Lotus spreadsheet errors

Tony Lauck <tlauck@CERF.NET>

Thu, 09 Mar 1995 09:46:17 -0500

Errors in financial calculations are not new.  When I worked at Autex, Inc.
in the early 70's I wrote a program to calculate bond tables.  I was told
that my calculations, right or wrong, had to agree with a certain book that
all the traders used.  Bond prices were given in dollars and cents and I was
told that a difference of one cent was unacceptable.  A one cent error in a
large trade could easily cost more than a Wall Street lunch for two, hence
was significant.

The bond table book gave the formula used and indicated the method of
rounding.  It was very easy to duplicate these calculations,  but would they
agree using a different processor?  By printing out my own version of the
book and comparing each entry by hand I found only a single error, in the
amount of one cent.  In the early 70's fancy desk calculators still ruled.
The one I happened to have had a switch that controlled rounding mode (down,
up, halfway)  so it could do interval arithmetic. Cranking the calculation
on this calculator to 15 digits I was able to bound the correct value.  It
was almost exactly halfway between two pennies, and my rounding was correct.
(This didn't surprise me as I had used 64 bit floating point,  a large
number of guard digits indeed for a four decimal place answer.)

Knowing that I was right and the book wrong was a nice position. I discussed
this with my boss and we decided to stick with our value.  I secretly hoped
there would be a dispute someday between two traders over this entry,
figuring that I could somehow turn this into a nice lunch.  No such chance.

Do people still use these old tables?  How many have errors?

Loss of one of the X-31 research airplanes

<ladkin@techfak.uni-bielefeld.de>

Mon, 6 Mar 1995 00:22:37 +0100

Flight International, 1-7 February 1995, reports the loss of a
Rockwell-Daimler-Benz Aerospace X-31A enhanced fighter-manoeuverability
research aircraft on 19 January 1995. `Investigations [..] are
focusing on the air-data system, say sources close to the project.
  "There is a possibility that hardware operation of some of the systems
may be involved [and] it cannot be excluded that the instruments were
giving false readings," says one source, adding that there is no indication
that the aircraft's advanced flight control system was involved [..].'

Flight International, 8-14 February 1995, reports that investigations are
centred on the pitot-static system (which measures altitude and airspeed by
means of pressure differentials, and that pitot icing is suspected by some.
`The aircraft was [...] in straight-and-level flight, when [the pilot]
detected false airspeed readings, followed by pitch oscillations. These
increased and were followed by a violent roll before [the pilot] ejected.'

So, investigators suspect that false sensor readings caused by icing-up of
the sensors led to inappropriate actions of the flight control system which
led to loss of control.  Generally, airplanes which may fly in instrument
conditions, i.e. clouds, including my Piper Archer, are equipped with pitot
heat to avoid similar problems, but if my pitot ices up, all I lose is my
airspeed indicator, and not my control. A colleague who is a Chief Engineer
at NASA Dryden, where the accident took place, points out that airplanes
such as F4s, which are not fly-by-wire airplanes, have also been lost when
false sensor readings led to inappropriate actions of the flight control
system - but in the case of an F4 it is a mechanico-hydraulic system rather
than a computer.  She suggests that a distinction be made between the flight
control system itself, which implements the control laws, and the system
that sends signals to the actuators to wiggle the control surfaces.

While we may not be able to ascribe the `fault' to a `computer' in this
case, it does raise the continuing issue as to how one ascribes faults.  It
is always possible in theory to replace a computer control system by wires,
pulleys, hydraulics, bells and whistles - but not to fit all this hardware
in the same airplane all at the same time. For example, Airbus argues that
its computer-controlled airplanes are `evolutionary', that is, the same
control characteristics could be achieved with more traditional control
systems - and the only consequence of computer control is weight savings,
and therefore extended range or the ability to carry more passengers. This
is debatable. The more interconnection between systems contributing to
control (possible when most things are software unless extreme care is
taken), the more opportunity for an inappropriate sensor reading to send
everything haywire. The X-31 would not be able to fly without computer
control. It is true that any individual system fault may be replicated by
means of wires, pulleys and hydraulics. But I doubt that this knowledge
would help anyone to analyse the fault and prevent its reoccurrence. I
suspect that techniques developed by computer scientists for dealing with
safety-critical computers are more useful.  Whereas in the case of my
Archer, only plumbers would be involved ........

Peter Ladkin

PGP Moose: moderator authentication and antispamming tools

Greg ROSE <Greg_Rose@sibelius.sydney.sterling.com>

10 Mar 1995 20:28:33 +1000

-----BEGIN PGP SIGNED MESSAGE-----

PGP Moose
=========
by Greg Rose <Greg_Rose@sydney.sterling.com>

The aim of this software is to monitor the
contents of consenting moderated newsgroups, and
to automatically cancel messages that appear in
the newsgroup without having been authorised by
the moderator(s) of the group. This has
(obviously) been prompted by the recent spammings.

PGP, the crux of the cryptographic software, was
written by Phil Zimmermann <prz@acm.org>, who
otherwise has nothing to do with this. The
cryptographic framework was written by Greg Rose
<Greg_Rose@sydney.sterling.com>. The INN news
system hooks are being provided by Chris Lewis
<clewis@ferret.ocunix.on.ca>.


How Does It Work?
- -----------------

When a moderator wants to protect their group from
forged/unapproved postings, they should register
their interest with one or more of the sites
running PGP Moose, and pick up the submission
script. As part of this process, the moderator
would specify a PGP public key that is allowed to
approve postings.

When a post comes in, and the moderator wishes to
approve it, they do whatever they would normally
do before actually using inews (or whatever) to
post the message. As their last action, they run
the PGP Moose Approval program "pmapp". This
inserts a special form of Approved: header which
looks like this:

Approved: PGP Moose V0.9 950310 sci.crypt.research
      iQBVAgUBL1/Kg2zWcw3p062JAQEYIgH/Xyrz6LaGG+fHaSxoexMECovzkIoADrQx
      l73IXlUQEIoFl5jnDBBdHVvqTMEPS0118ytYVQZoQrdStuXB9Oc9gQ==
      =azqs

In this example you can see that the approval
carries a date stamp and the name of the newsgroup
in question. These, as well as the From: and
Subject: lines, and the non-blank lines of the
message itself, are used as input to the PGP
program to generate a signature. The PGP signature
is the inserted into the Approved: header, mostly
so that it won't interfere with, or be confused
with, any signature in the body of the message.

Anybody can check whether the message has been
modified in any significant way, simply by running
the PGP Moose Approval Checking program "pmcheck".
More importantly, though, the sites running the
PGP Moose Checking Daemon will be doing this
automatically for every posting to the registered
newsgroups. And, if a posting fails the checks, it
will be automatically cancelled and a notification
sent to the moderator.

This software is made freely available for just
about any purpose, but I've retained copyright so
as to keep some semblance of involvement. See the
last section of this file.


The Bits:
- ---------

PGP Moose consists of a number of Bourne Shell
scripts calling standard Unix utilities and PGP.
I could have used perl more elegantly, but this
stuff is marginally more widely available.  If
there are Unix version dependencies, they should
be considered to be bugs and I'll happily attempt
to remove them.

pmapp   usage: pmapp newsgroup [file]

    This script takes the not-yet-posted
    article, specified either by filename or
    from standard input, and creates a
    signature for it, which is then inserted
    in the Approved: header. The article,
    ready for posting, appears on the standard
    output.

    In the configuration section at the top of
    the script, the moderator may build in the
    PGP User Id to be used for the signature,
    and the corresponding password. This is
    simply for convenience, since spammers are
    not so likely to go cracking the computer
    to get the password, and it is a
    relatively simple matter to generate a new
    user if it is, indeed, compromised. For
    the paranoid, like myself, if the password
    is not configured into the script it is
    read from the terminal instead.

pmcheck usage: pmcheck [article]

    This script takes the article, specified
    either by filename or from standard
    input, and checks that the Approved: line
    is something it considers to be correct
    and that the article has not been
    tampered with. Pmcheck returns
    successfully if everything checks out.
    Otherwise it will return failure and
    issue one of a number of error messages,
    for example:

      Usage: $0 [article]
      Posting not approved with PGP Moose.
      Wrong newsgroup: $6 != $GROUP.
      Bad signature (altered or damaged file) on $FILE.
      Signature '$SIG' on $FILE invalid for newsgroup $GROUP.

    Anybody can run pmcheck. It behaves
    slightly differently depending on the
    existence of a file called (by default)
    PGP_Moose_accept. This file, if it exists,
    should contain lines with a newsgroup
    name, some whitespace, and the PGP User Id
    approved by the moderator (usually made up
    specifically for this purpose). For
    example:

      sci.crypt.pgpmoose       pgpmoose test <ggr@sydney.sterling.com>

    If such a file exists, pmcheck is silent
    if all is well, and issues the last of the
    error messages above if everything else
    was all right but the signature was from
    the wrong person.

    Without such a file, if the signature is
    otherwise valid you will get a message
    like:

      Valid signature from '$SIG'.

A script is being developed by Chris Lewis (who
has more control over news stuff than I do) which
will perform the automatic cancellations. Stay
tuned. There is plenty of prior art, so this
shouldn't take too long.

Soon, when I get back from my trip in two weeks,
I will create mail server scripts that allow
moderators who are not using Unix to use these
facilities.  The first allows a moderator to mail
a PGP signed copy of the article to be posted.
The server will then verify that the moderator
sent it, and post it with a (different but
corresponding) approval. The second will accept an
article and return something that you can check
the signature on. Either way, any moderator will
still need PGP.


How Do You Register For The Service?
- ------------------------------------

Ahhh, this is the hard part. After all, it would
be pretty undesirable if someone, meaning well,
took any old body's word for it that some
important moderated group should start working
this way, before the moderator was able to start
approving postings. A great way to hijack a
newsgroup.

Another possibility is that someone, having seen
what the valid signature looks like, simply
creates a whole new PGP key that happens to have
the same PGP User ID. Then they can sign and post
stuff too.

The solution to both of these problems is the
classical one for public key systems. You need
either a certifying authority or the PGP Web of
Trust. We're using the Web of Trust. If you don't
understand about PGP and the Web of Trust, go away
now and come back after you really do understand
it.

For each newsgroup that wants to utilise this
program, the moderator will have to create a
special PGP key pair (preferably 512 bits to keep
the Approved:  lines short), and sign it. They
must then establish a path of trust to someone
who is running the PGP Moose server. It will be
up to the administrator of that server to make
sure that only trusted moderators' keys ever get
into the server's keyring.

THERE CAN BE NO SHORTCUTS TO THIS PROCEDURE.
Otherwise we are all back where we started.


What If You Have Multiple Moderators?
- -------------------------------------

Simple. Create one PGP key pair which can approve
posting, and share it among the moderators. You
have to exchange it securely, but by definition
you have PGP, so that shouldn't be too hard. You
can still tell which moderator approved a posting
from the Sender: line.


Possible Problems We've Forseen:
- --------------------------------

If an article is mangled e.g. by truncation, it
will fail the authentication and be cancelled.
Until it is demonstrated otherwise, this is
assumed to be a rare and minor problem. When a
cancel is issued, mail is sent to the moderator of
the group telling them, and they can tell us if it
becomes a problem.

Currently the signature produced is assumed to be
a PGP version 2.6 compatible one.

The moderated newsgroup in question must be the
first newsgroup on the Newsgroups: line; as a
corollary it is not possible at the moment for an
approved posting to multiple moderated newsgroups.

Only one PGP User Id can approve postings to a
particular group. This means that that PGP User's
private key must be shared between all of the
moderators, with all of the attendant risks.


Status:
- ------

These scripts are implemented already, or as noted
above. They are undergoing testing by Chris Lewis
<clewis@ferret.ocunix.on.ca>, and as soon as they
have settled (within a week for sure) they will be
made available via anonymous FTP and posting to
comp.sources.misc and sci.crypt.research.


It Really Wasn't That Hard.
- ---------------------------

I wish people (other than me and Chris Lewis) had
put as much effort into doing this as they did
into clogging the Moderators' mailing list. It
wasn't hard.

But you know what was hard? What Phil Zimmermann
did creating PGP in the first place. Phil is in
serious legal hassles over PGP, and if you think
this effort saves you or your company some time or
money, I'd like you to consider donating some of
it to Phil's legal defence fund. Write to me or
Phil's lawyer Phil Dubois <dubois@acm.org>
regarding how to donate. You can do it over the
net using PGP!

Share and Enjoy!


License Terms
- -------------

This software is copyrighted by Sterling
Software, and other parties.  The following terms
apply to all files associated with the software
unless explicitly disclaimed in individual
files.

The authors hereby grant permission to use, copy,
modify, distribute, and license this software and
its documentation for any purpose, provided that
existing copyright notices are retained in all
copies and that this notice is included verbatim
in any distributions.  No written agreement,
license, or royalty fee is required for any of
the authorized uses.  Modifications to this
software may be copyrighted by their authors and
need not follow the licensing terms described
here, provided that the new terms are clearly
indicated on the first page of each file where
they apply.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE
LIABLE TO ANY PARTY FOR DIRECT, INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF THIS SOFTWARE, ITS
DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN
IF THE AUTHORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY
DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT.  THIS SOFTWARE IS
PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND
DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
MODIFICATIONS.

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBL2Ao0aRQkCwJ0+ZNAQEC5QQAzYC388xAkKCG+737mOLH0Bg3vbPnlSPO
4epkvW7GD6HyaCUq34mhqYx2h1gCn4ywRG0bTZbjOyEMjU9d78Xyar/abu+jkMGc
umwwbcNHssYfsHMsfbrUR8vVz2C8+5ULUyavN9aNRIlFTpekWGklYfa+NGtIB84I
Xr9QW8Y2TqY=
=tjMn
-----END PGP SIGNATURE-----
Greg Rose, Sterling Software, 28 Rodborough Rd., French's Forest. NSW 2086
Australia.  +61-2-975 4777 (FAX: +61-2-975 2921) greg_rose@sydney.sterling.com

Report problems with the web pages to the maintainer