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 88

Weds 8 March 1995

Contents

o Caller ID Ghosts
Jim Huggins
o Interesting cellular news from Pakistan
Abhijit Dutta via Ben Burch
o Re: Microsoft and Lotus spreadsheet errors
Barry Margolin
o Re: Confused remotes
Philip H. Smith III
o Re: The source of semantic content
Steven Tepper
o Re: The source of semantic content
A. Padgett Peterson
o Re: The source of semantic content
Barry Margolin
o Re: The source of semantic content
Jeremy Epstein
o Re: The source of semantic content
Jon Krueger
o Re: The source of semantic content
Tim Kolar
o Re: The source of semantic content
David Harpe
o Re: Sparc10 keyboards and resetting the CPU
A. Harry Williams
o Re: Sparc10 keyboards and resetting the CPU
Simson L. Garfinkel
o Re: Sparc10 keyboards and resetting the CPU
Ed Bruce
o Re: Sparc10 keyboards and resetting the CPU
Mark Stalzer
o Re: Sparc10 keyboards and resetting the CPU
David Honig
o Info on RISKS (comp.risks)

Caller ID Ghosts

Jim Huggins <huggins@eecs.umich.edu>
Wed, 8 Mar 1995 10:20:31 -0500 (EST)
News item from the Detroit Free Press, 8 March 1995.

A Detroit area woman last week looked at her Caller ID box (manufactured by
CIDCO, Morgan Hills, CA) and was puzzled to notice that it indicated 19
received calls that evening, even though only one person had called.  Then
she checked the names listed.  John F. Kennedy.  Thomas Paine.  Harry S
Truman.  John Hancock.  Ulysses S. Grant.  Samuel Clemens.  Ronald Reagan.
And many others.

Most of the phone numbers were non-working, but a few were.  Ryan Biermann,
an English student at the University of Wisconsin-Madison has been plagued
with phone calls for Abraham Lincoln recently.

No definitive explanation has been given.  Ameritech (the Baby Bell
for Detroit and Madison) believes the Caller ID box was probably
a pre-programmed demonstration model.  Dave Glowacz, a telecommunications
consultant in Chicago, suspects the work of a phone hacker.

Depending on the cause, lots of old Risks here (either a faulty
demonstration circuit with non-fake data or an insecure data system), but
perhaps with a new face to them.

Addendum: accompanying the article is a photo of the Caller ID box listing
Abraham Lincoln's name and phone number.  I hope Mr. Biermann won't be
getting too many more phone calls because of it ...

Jim Huggins (huggins@umich.edu)


Interesting cellular news from Pakistan

Burch Ben <Ben_Burch@wes.mot.com>
Mon, 6 Mar 1995 17:21:30 GMT
  From misc.news.southasia Sun Mar  5 17:56:49 1995
  From: abdutta@icaen.uiowa.edu (Abhijit Dutta)
  Date: Sun, 5 Mar 1995 00:34:16 GMT
  Newsgroups: misc.news.southasia
  Subject: Pakistan Forces Motorola To Halt Cellular Services In Karachi

  Voice of America, March 04, 1995
  By Jennifer Griffin

  Islamabad: The Pakistan government has forced the US telecommunications
  giant, Motorola, to halt mobile telephone service to the country's
  strife-torn city, Karachi. Pakistani officials are demanding Motorola
  hand over sophisticated eavesdropping equipment that would allow
  intelligence agencies to tap into phone calls made on the company's
  cellular network. Analysts are saying the  government's action is not
  encouraging to foreign investors.  The Pakistan government claims it is
  trying to crack down on Karachi terrorists using mobile telephones to
  coordinate attacks and organize violence in the ravaged city.

  In a memo to James Beneda, the president of Mobilink -- Motorola's
  Pakistani joint venture -- the communications ministry demanded
  equipment needed to tap into all calls made by its subscribers be given
  to the government.

  Without these sophisticated scanners, intelligence agents would not be
  able to tap into the cellular network.  It is the first time the
  government has admitted such tapping and eavesdropping is commonplace
  in Pakistan.  Mobilink's service to Karachi was cut by the government
  January fourth.

  According to Mobilink's regional manager, Zahid Hussain, two other
  cellular phone companies presently operating in Karachi have not had
  their service interrupted because their calls are easily tapped. "The
  facility the other two cellular companies have, all you do is buy a
  200-dollar scanner from Hong Kong or wherever, and you can walk the
  streets and just keep tuning into different frequencies and listening
  to people's conversations."

  Mr. Hussain says his company will comply with some of the government's
  demands and will deliver the mobile scanning equipment sometime this
  month.  But, there remain other obstacles to resuming operations.  The
  government has also demanded Mobilink not expand its number of
  subscribers from the present 3000 -- a request mobilink officials say
  they cannot possibly honor.

  US state department officials and Secretary of Commerce Ron Brown are
  said to have brought the matter to the attention of Pakistan's
  Washington Ambassador, Maleeha Lodhi.

  The US-based company has invested more than 32-million dollars in
  establishing its Pakistani operation since last August, and intended to
  invest nearly 20-million dollars more this year.

  The scandal has caused many foreign businessmen to rethink their
  investment in Pakistan, where they say licensing agreements are easily
  rewritten and often disregarded.  Mr. Hussain says the government's
  handling of the incident sends a negative signal to foreign investors,
  particularly on the eve of prime minister Benazir Bhutto's trip next
  month to the United States.

Ben Burch  Motorola Wireless Data Group  Ben_Burch@wes.mot.com


Re: Microsoft and Lotus spreadsheet errors (Hunt, RISKS-16.87)

<barmar@nic.near.net>
Wed, 8 Mar 95 06:17:33 EST
>Barry Ward, ... `I've been in the computer business for 19 years and
>have never come across this problem before.  ...

I find it difficult to imagine someone who's been in the computer business
for two decades and has never heard of floating point round-off errors.
This should be part of any computer science curriculum.

Of course, part of the problem is that 20 years ago, virtually all business
software was written in COBOL or PL/I, and that's probably Mr. Ward's
background.  These languages provide fixed-point decimal as a built-in data
type, and require that decimal arithmetic be done accurately.  There may
still be round-off errors (e.g. dividing 100 by 3, or multiplying .01 by
.01 and putting the result in a variable with two digits after the decimal
point), but the programmer has direct control over the level of precision.

These days, end users use spreadsheets to write "business software", and
the spreadsheet designers seemed to have forgotten how business software
has traditionally worked.  The spreadsheet implementors are simply using
the built-in mathematics that C provides, which is not appropriate for this
problem domain.  Floating point was designed for scientific computing --
it's often not much of a problem that errors are introduced, since there's
an inherent imprecision in the input data (since it's translated from the
analog real world to the digital cyber world).

Barry Margolin, BBN Internet Services Corp. barmar@near.net


Re: Confused remotes

703) 506-0500 <PHILS@RELAY.RELAY.COM (Philip H. Smith III,>
Wed, 08 Mar 95 07:59:24 EST
Re: the various appends about lights, etc., fooling remote controllers: I
used to have a Jerrold cable box that had a clock in it.  When I used my
stereo receiver remote, it would sometimes cause the Jerrold clock to jump
an hour.  What was interesting about this was that this was NOT a function
offered by the Jerrold remote!  ...phsiii

    [This is a clock that goes JERROLD McBoing-Boing when it triggers
    the alarm?  If it change the right <left?> digit, it would become a
    YEAR-OLD clock.  PGN]


Re: The source of semantic content (RISKS-16.87)

Steven Tepper <greep@datatools.com>
Tue, 7 Mar 95 21:51:17 PST
>   [The situation is even more complicated by the availability of
>   programs that mask encrypted messages as graphical image files
>   (.gif), so that irrespective of their REAL content, a message
>   appears to be an innocuous picture.  PGN]

What about going in the other direction?  If you take an image file or some
other data file (say a core dump file) that appears random, apply some
simple operations (say XOR with various values) to it and run the output
through a program that filters out everything except strings of
alphanumerics (such as the Unix "strings" program), eventually you're bound
to come up with with something that contains some obscene words, possibly
"misspelled".  A zealous prosecutor could use this to "prove" that the
original was an encrypted form of obscene text.


Re: The source of semantic content (RISKS-16.87)

A. Padgett Peterson <padgett@tccslr.dnet.mmc.com>
Wed, 8 Mar 95 10:17:21 -0500
   [The situation is even more complicated by the availability of
   programs that mask encrypted messages as graphical image files
   (.gif), so that irrespective of their REAL content, a message
   appears to be an innocuous picture.  PGN]

Let's consider something even easier: Take a digital picture "A" of a
politico presenting an award. Using a graphics editor, a miscreant
removes certain items and adds a mustache (or something). The two
digital files are then XORed so that only the changes remain in file "B".

Again we have a two part solution but now the first part is mixed so
that the second becomes a night sky or lost in the 24th bit of the first.

Viewed as sent, it is an innocuous picture, but rearranged...

Can you see the prosecutor trying to explain "yes but if you switch this
and change that color and twitch you nose it becomes...

Kinda like the person (not catching me with that one) complaining of
the indecent behaviour next door: "Yes officer, it's horrible. Just
climb out here on the roof of the garage, lean against that light pole
and with these infrared binoculars you can see it just as plain..."

"Life will find a way".  Padgett


Re: The source of semantic content (Gat, RISKS-16.87)

<barmar@nic.near.net>
Wed, 8 Mar 95 06:17:33 EST
>If A and B exchange P in this way, then they can individually publish F1 and
>F2, from which anyone can recover P, but both A and B can plausibly deny
>having done anything but publishing a random bit stream.

Unless they actually didn't know what the purpose of those random bit
streams were, they would be perjuring themselves.  They would have to
convince a judge (and maybe jury) that they really thought they were just
random bit streams, and they were passing them to each other for no reason.
Were I on the jury, I would be skeptical.

Barry Margolin, BBN Internet Services Corp. barmar@near.net


Re: The source of semantic content (Gat, RISKS-16.87)

Jeremy Epstein -C2 PROJECT <jepstein@cordant.com>
Wed, 8 Mar 95 10:11:09 EST
In RISKS-16.87, gat@aig.jpl.nasa.gov (Erann Gat) had some very clever
comments about ways of exchanging bit streams that together make up a
picture.  I'd propose another scenario: if U1 embeds a pornographic image in
the background of a picture, and sends U2 a binary image of the picture, U2
may well be unable to detect it.  If U2 forwards the picture to U3, who (if
anyone) has violated the proposed Exon law?  As was shown in a paper
published at the 1993 Computer Security Applications Conference, an amazing
amount of data can be embedded in a digital picture without it being visible
to a human looking at the picture on a screen or on paper.

Truly amazing how little insight our legislators have into the
technology they're trying to legislate.


Re: the source of semantic content

"Jon Krueger" <jpk@pet.com>
Wed, 08 Mar 1995 01:58:08 PST
> [encrypt image file F1 with one-time pad F2, email F1 to person A
> and F2 to person B; A and B then exchange F1 and F2]
> A and B each can now recover the original image. Has the law been
> broken?  Who broke it?  All anyone did in the above scenario was to
> send a random bit stream to someone else.  At no time did anyone send
> a bit stream with any identifiable semantic content.

An undeveloped photo becomes evidence of crime when it's developed and
is deemed porn.  A special film requiring its own developing process
doesn't change this.  Whether a crime was committed wouldn't rest on
mechanisms of imaging, therefore, but on the image transmitted.  If
it's deemed porn, chances are all three of you broke the law (plus
conspiracy to commit same, given the way you went about it.)  Lectures
to judge or jury on the mathematical properties of the tools used will
probably seem to them like lectures on thin film chemistry.

> One might argue that I broke the law by sending out two files that I
> knew could be combined to produce a pornographic image.

That would be the prosecution's argument, yes.

> So imagine now that A sends a random bit string F1 to B, who then uses
> this as a one-time pad to encode P, which B then sends back to A.  Has
> the law been broken?  Who broke it?

A has conspired with B to effect the transmission of images deemed
pornographic from B to A.  I wouldn't bet the rent on any judge or
jury concluding anything else.

> B could never be convicted of violating the law, since he could always
> claim that he had sent F2 before receiving F1, and that therefore A
> had transferred P to him rather than vice versa.  Even if the
> government had timestamps to show that F2 was sent after F1, B could
> claim that this was simply a retransmission.

Oh?  We couldn't recover P from A or B's storage?
Or talk to someone who knew where P came from?
If we do, we don't need to know anything about F1 or F2.
We know where P came from and where it went to.

Even without that, if timestamp records conflict with B's claims,
we simply have to choose which one we believe.  B's claims might
be found credible, and might not.  The judge or jury decide.

On either grounds, B's toast under a variety of circumstances.

> If A and B exchange P in this way, then they can individually publish
> F1 and F2, from which anyone can recover P, but both A and B can
> plausibly deny having done anything but publishing a random bit stream.

The key word here is "plausibly"; plausible to whom?  Judge or jury
might find it less than plausible that A and B engaged in the generation
and distribution of random bit streams, which later just happened to
form images in combination.

> The DA might try to prosecute both A and B on a conspiracy charge,
> but it is not necessary for A and B to have conspired.  The mere
> knowledge that random bit streams can be used in this manner might
> prompt some people to start sending random bit streams around.
> Without reliable time stamps there is no way to trace the introduction
> of semantic content.  So as soon as anyone starts to transmit
> one-time-pads, everyone can publish anything and no one can be
> prosecuted for it.

The above discussion should demonstrate why this is a rather
naive view.  However anyone who wants to give it a whirl is
welcome to; it's your nickel.  The danger lies instead in
an equally naive view:

> Any attempt to legislate the content of digital communications is
> therefore doomed to fail

And therefore we need do nothing.  Wrong.  The fact is that clever
games such as these will not impress the judicial system nor derail
the legislative process.  If the law gets on the books it will work
its damage.  Such schemes as suggested above will be looked on as
what they are, attempts to evade it or confuse its enforcement;
little will be gained; it might even be counterproductive.  No,
if we want to stop Senator Exon's nonsense, we have to do it the
old fashioned way: organizing, lobbying, informing, and persuading.

Jon Krueger  jpk@pet.com  (510) 523-2514


Re: The source of semantic content (Gat, RISKS-16.87)

Tim Kolar <tkolar@cisco.com>
Wed, 8 Mar 95 10:09:29 PST
Erann Gat's article on semantics (RISKS-16.87) provides a nice example of
the difficulties of identifying any bit stream with certainty.
Unfortunately it also provides an example of an all too common Risk:
Engineers confusing scientific "proof" with that of a legal nature.

Censorship is already enforced on the internet.  In particular, allowing
transfer of encryption technology out of the U.S. is illegal.  This leads
to awkward situations for companies who's products include security, but
by Gat's arguments they can get around the problem by simply encoding the
software and sending it as two "random" bit streams.  Anyone who decides to
try this, please be sure to let us all know...

Sarcasm aside, I don't think anyone believes that Department of Commerce
(or Defense, or whoever enforces that restriction) would even slow down
on their way to the courthouse because the information was encrypted.  Intent
is far more important than encoding, and I don't believe they'd have any
trouble with a conviction.

But back to the basic Risk:  Engineers forgetting the end users and
getting wrapped up in notions of mathematical certainty and "solid" proof.
Remember:  your firewall _supports_ an overall security policy.  Your
automated flight system _supports_ a pilot.  Your software filters _support_
the legal system.

In all these cases the software is not the end all be all, but an aid to
accomplishing some other task.  At some point we may feel comfortable
replacing humans with software completely for these uses, but RISKS forum
itself is a testimony to how far off that actually is.

-Tim Kolar


Re: The source of semantic content (Gat, RISKS-16.87)

<David_Harpe@mm.cobb.ziff.com>
Tue, 07 Mar 1995 22:46:57 -0500 (EST)
>Now suppose that I email F1 to person A and F2 to person B.  Then A and B
>exchange F1 and F2.  A and B each can now recover the original image. Has
>the law been broken?  Who broke it?  All anyone did in the above scenario
>was to send a random bit stream to someone else.  At no time did anyone send
>a bit stream with any identifiable semantic content.

Unfortunately, our legal system is not advanced enough to recognize the
subtle differences described above.  The authorities will wait until the two
parts are combined.  They will then seize every piece of hardware which
appears to be associated with the image.  Anyone who happens to be in the
mail header will be arrested.  During the trial, the reconstructed image is
all the jury will see, understand or remember.  They will fall asleep during
the expert witness testimony regarding public key cryptography.  This is the
RISK of living in a society which is heavily dependent on technology, but
whose users are not very well educated.

David Harpe  david_harpe@mm.cobb.ziff.com


Re: Sparc10 keyboards and resetting the CPU (Neustaedter, 16.85)

"A. Harry Williams" <HARRY@VM.MARIST.EDU>
Fri, 03 Mar 95 18:54:41 EST
>Actually, this is a feature.

I'm sorry, but throwing a user into an unknown state and requiring them to
know they have to type "go" and calling it a feature simply because the
operating system can't handle losing power without risk of losing the file
system is wrong.  It's a kludge covering a bug.  It never ceases to amaze me
the ends to which people will put up with this from vendors.  They won't fix
the original bug, but they will add on all sorts of backdoor patches and
think they've solved the problem.  It would be like taking your car in for
service for a rattle, and and the garage giving you ear plugs so you can't
hear it anymore.

To steal a line from the same Risks issue, the ultimate solution to these
recurring file system problems is for consumers to demand working file
systems from software manufacturers.

/ahw


Re: Sparc10 keyboards and resetting the CPU (Neustaedter, RISKS-16.85)

Simson L. Garfinkel <simsong@acm.org>
Fri, 24 Feb 1995 21:22:53 -0500
I would like to take issue with Tarl Neustaedter for saying, in effect,
that Sun's decision to have its SPARC computers go into the ROM Monitor
when you unplug the keyboard is a FEATURE and not a BUG.

Mr. Neustaedter eloquently says, basically, the following:

        1. Sometimes you need to be able to interrupt the computer.
        2. User software can completely remap the keyboard.
        3. Therefore, we need some signal that can't be remapped to get the
           user into the ROM Monitor.
        4. The only thing left is unplugging the keyboard and plugging it
           back in.

Here are some things to consider:

        1. First at fault is the ROM monitor itself, which has one of the
most un-user-friendly prompts I have ever seen. The menus are difficult to
read; the commands are not neatly formatted; it's just not clear for
non-technical people what to do.

        2. I am sure that more files have been left by some poor secretary
or other non-technical person accidentally unplugging the keyboard and then
plugging it back in (and consequently getting trapped at the ROM prompt),
then have been saved by UNIX weenies who have known that they could trap
into the ROM monitor by playing this game with the keyboard plug.

        3. Mr. Neustaedter's note that this functionality can be disabled
by hand-editing the function call to abort_sequence_error() in the function
zsa_xsint() in the file zs_async.c is the typical UNIX weenie response: if
you don't like it, then search through the source-code (or object code) and
fix it yourself.

        Yes, it is wonderful that UNIX gives its users such flexibility.
But it's also clear that UNIX was designed for small research labs where
the users want this sort of flexibility, and not for general use. Putting
UNIX into general distribution is dangerous: it's dangerous for the users,
and dangerous for those who have to give support to the users.

        "It helps to be handy with kadb."

        Indeed.

        Simson L. Garfinkel
        Co-Editor, "The UNIX-HATERS Handbook", IDG Programmer's Press, 1994.


Re:Sparc 10 keyboards and resetting the CPU RISKS (DIGEST 16.83)

Ed Bruce <edward@igate1.HAC.COM>
Thu, 23 Feb 1995 09:06:53 -0600
This has been a feature of Sun Workstations at least since the Sun-2s. I
worked on a project in 1985 with six rack mounted Suns each supporting 6
diskless Suns. There was a table beside each rack and on the table was a
keyboard. No CRTs of any kind to be seen. I don't know why, but periodically
someone would decide that they needed one of these keyboards.  With the
result that at least six Suns (generally more as NFS mounts to the now hung
server would fail) would freeze up until we could get the keyboard back and
reboot the server.

Just last year I was stung by this feature. I was to give a demo on a Sparc
10. Some one had connected the mouse off the left side of the keyboard and I
decided I needed it on the right. So I immediately unplugged the mouse then
proceeded to disconnect the cable on the right side, and the Sparc 10
proceed to crash. After reconnecting the cables I attempted to reboot. Well
it failed to reboot and later it was discovered that one key file had been
corrupted (I forget which one).


Re: Sparc10 keyboards and resetting the CPU

Mark Stalzer <mstalzer@etsd.ml.com>
Mon, 27 Feb 95 08:38:05 EST
This is a good topic for a trivia question in the Computer Bowl. I bet SMI
borrowed the break behavior from PDP-11s. I'm not sure when it was
introduced into the PDP-11 family (certainly by the mid 70's), but holding
the break key for a bit on the console caused a "framing error halt". On a
PDP-11/03, this dropped you into the microcode monitor. On machines without
a monitor, you had to restart it from the front panel with all the funky
lights.

Anyways, it served a useful purpose. On the RSX-11 operating system, you
could schedule a job with a priority higher than the command line
interpreter.  If this job went into an infinite loop, it could not be
terminated.  The solution was to stop the machine with the break key, and
poke around in kernel memory to remove the job (there were various ways to
do this.) Hopefully, when the machine was restarted, it would be back to
normal.

  -- Mark Stalzer (mas@acm.org)


Re: Sparc10 keyboards and resetting the CPU (Puchol)

David Honig <honig@binky.ICS.UCI.EDU>
Mon, 27 Feb 1995 17:09:34 -0800
Disconnecting the keyboard is the same as the L1-A interrupt which throws
Suns (since Model 3s) into their monitor program.  Typing "c" for continue
will let the cpu resume unixing.

This is indeed obscure behavior if you don't know about it :-0 Most
computers have arcane stuff like this mentioned (once) in their voluminous
manuals.

Computers aren't the only such systems: there are cars you can shut down by
kicking in the right place, where you activate a sensor that shuts off the
fuel pump, for instance.

The problem with big systems is no one reads (or understands) whatever
descriptions of it there might be.

Please report problems with the web pages to the maintainer