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 9 Issue 68

Wednesday 14 February 1990


o Re: Caller ID (NYTimes editorial)
John M. Sullivan
o How to make answering machines deliver ransom messages
Denis Coskun
o More on the Hubble Space Telescope
Hank Strub
o Human blamed, not the computer! -- jury duty
Lee S. Ridgway
o Accents are more than just decorations
Kai-Mikael J{{-Aro
o [Parse-ly, Rosemary, Time, Light, Control & Other SAGE Remarks]
Martin Minow
o Blazers
Jeff Berkowitz
o Re: Computers, good and evil
Gregg TeHennepe
o Telephone Switch Security
Roland Ouellette
o Info on RISKS (comp.risks)

Re: Caller ID (NYTimes editorial)

John M. Sullivan <sullivan@math.Princeton.EDU>
Fri, 9 Feb 90 20:27:26 -0500
An editorial in the New York Times this morning (Feb 9) entitled
``Obscenities, Hang-Ups and Technology'' discussed Caller ID, the new
phone feature showing the caller's number before the phone is answered.
It discussed the privacy issues, namely the enhanced privacy of those
who no longer receive obscene calls, and the reduced privacy of those
placing calls.  Suppposedly it is ``a potent deterrent that already
seems to have sharply reduced those annoyances [crank calls] in New Jersey.''

Then it mentioned Call Blocking, an added feature not available in New
Jersey, but to be available for free in California:
    ``By pressing two or three keys, callers could keep their
    numbers from being transmitted.  The recipient would not
    see the number on the screen, only a 'P' [what do you
    suppose 'P' stands for?] or some other symbol.  Like an
    apartment dweller who sees that the front door peephole
    has been blocked, he could simply decline to respond to the call.
    The trouble with Call Blocking is that it undermines Caller ID.
    Why would people buy Called ID if it could be so easily defeated?''

The answer is easy: they would for the same reason they install
peepholes--they will know when it is being defeated.

The editorial goes on to distort the balance of privacy issues:
    ``Three privacy interests intersect here.  It is difficult choosing
    between two--the interest of the recipient of calls who wishes not
    to be harassed and the interest of the caller who wishes no to be
    identified.  The third interest, however, might be overriding:
    society's interest in discouraging offensive phone calls generally.''
Simply repeating one side of the argument twice (from an individual and
a societal point of view) does not make it carry twice the weight.

The editorial concludes that a bill sponsored by Sen. Herbert Kohl to
require free Call Blocking should be defeated, until the impact on
privacy of Caller ID with and without Call Blocking can be measured.

I wrote a response to the editor, which concludes:

Even without Call Blocking, those wishing to harass could do so
anonymously from pay phones.  But this might be too much discouragement for
those wishing to place anonymous calls to crisis hotlines, as you suggest.
Of course the organizations running those hotlines can probably be trusted
not to use Caller ID to trace their calls.  But people considering placing
such calls need all the encouragement they can get to go ahead without fear
of identification.

The real danger to society in Caller ID comes from the ability of large
companies to maintain databases by phone number.  It will be convenient if
corporations can quickly identify and service their regular customers by
looking up the phone number when a call comes in.  But one might wish to
make a call inquiring about some product without running the risks of
receiving follow-up calls or being placed on a related mailing list.

Call Blocking provides the perfect solution.  While private individuals with
Caller ID would refuse blocked calls if they feared harassment, I am sure
that even those corporations that made use of a phone database would be
willing to accept some anonymous inquiries.

Although the drop in obscene phone calls is easy to measure, the risks
to callers' privacy are much harder to quantify.
I sense that you do not even plan to measure them at the end of the
experiment you propose, in which New Jersey will be the guinea pig.

John M. Sullivan    Princeton Univ. Math Dept.

Defeating answering machine security codes

Denis Coskun <dcoskun@alias>
Fri, 9 Feb 90 20:21:00 est
In RISKS-7.69 Vince Manis tells us that his General Electric
answering machine has only 256 possible access codes for remote
message retrieval.  I have the same machine.  Valid combinations
are 3 consecutive touch tones of the form [0-7][0-7][0-3].

In RISKS-7.73 William Curtiss points out that most answering
machines just ignore digits until you get the correct security
code.  "As long as the incoming stream contains the code
somewhere you are given access.  Since 256 combinations needs
three digits, a carefully constructed string of 258 digits will
contain every possible combination (for example, if the code is
a triplet composed of just the numbers 1 and 2 then the string
1211122212 contains all eight triplets)."

The shortest string of digits that I was able to generate for
defeating my answering machine was 452 digits:


DTMF decoding chips are required to recognize a tone as short
as 50 milliseconds with an interdigit interval of another 50
milliseconds, making a total of 100 ms for each digit.  So the
whole 452 digit string could be dialed within 45.2 seconds
using a demon dialer.  Since my answering machine will wait a
minute or more while you leave a message, it could be cracked
with just one phone call.

Can anyone suggest an algorithm to generate a shorter string
than I have above, or better yet, an optimal string?  A string
length of 258 digits is a lower bound, but is there necessarily
a solution that short?

I checked more than a dozen different answering machines on the
market that allow remote message retrieval using touch tones, and
the best let you select combinations of the form [0-9][0-9][0-9].
A key space of 1000 combinations is hardly any improvement.

Denis Coskun   utcsri!alias!dcoskun

How to make answering machines deliver ransom messages

Fri, 9 Feb 90 20:22:57 est
I discovered a security weakness that would allow you to trick
answering machines with remote message retrieval into making phone
calls and delivering untraceable ransom messages!

Here's how:

Dial someone's answering machine and leave a message with the format:
1.  14 seconds of nonsense talking (to keep the tape running)
2.  dial, say, 555-1234 using touch tones (which will be recorded)
3.  a few more seconds of random talking
4.  finally your ransom message

Now dial the security code (which you discovered as described in my
companion article) to get the answering machine to play back the
messages.  As soon as you hear the start of your nonsense message,
hang up.  The machine will continue playing the messages, oblivious
to the fact that no one is listening.  The telephone exchange will
supply dial tone to the answering machine's line 12 seconds after
you hang up (12 seconds at my exchange).  Two seconds later, the
answering machine will play the recorded touch tones 555-1234,
effectively dialing that number.  A few seconds later, the person
at 555-1234 answers and your message is delivered!  And it cannot
be traced to you.

Of course, you would call back the answering machine and clean
up the evidence.

I believe that the technique will work on all answering machines
with remote message retrieval provided that:

1. You have the security code (see my other posting about how good
   these are).

2. The exchange will supply dial tone to the callee after the
   caller hangs up.  This is true on all modern switches.

3. The phone line of the answering machine permits touch tone
   dialing.  This is a way to secure your answering machine:
   switch to pulse dialing only service.

4. The machine and its tape reproduce touch tones with enough
   fidelity.  Mine do.

5. The machine will ignore dial tone.  There are no guaranteed
   electrical changes on the line when a caller hangs up, so
   watching for dial tone would be the only reliable indicator,
   which my machine ignores.

6. The machine will record touch tones.  Mine will record
   everything (except that the 3 digit security code gets it to
   play back the messages).  The security hole could be plugged if
   the machine would stop recording as soon as it got any touch tone.

7. The machine will play all touch tones recorded on its tape.
   I did have some trouble here since the machine cannot tell if
   a tone is coming from the tape or from the caller on the line.
   During playback, my machine will interpret a "1" as a command to
   fast forward and "3" to fast reverse, and thus disrupt the
   dialing if these digits are part of the number.

A more likely hazard than untraceable ransom messages is the relaying
of long distance messages that are charged to some innocent answering
machine owner, or harassing the owner by having him billed for
random toll calls (long distance, overseas, 976, 900, etc.).

Denis Coskun   utcsri!alias!dcoskun

More on the Hubble Space Telescope

Hank Strub <>
12 February 1990 0909-PST (Monday)
The 2/11/90 New York Times Magazine has a long article on the space telescope.
This article goes into some detail on the project's software problems

    ". . .scientists were aiming for a 1985 launching, but because so much
    of the technology related to secret military systems, the Pentagon
    dictated that only 116 managers in the project could have access to
    the contractors' plans.  'This lack of manpower came back to haunt us
    many times,' Robert O'Dell, who now teaches at Rice University, wrote
    in Sky & Telescope magazine last July.  'It kept NASA from closely
    following the contractors' work and made it very difficult to know what
    was happening at any given time.
        Costs soared and deadlines were missed.  The system that
    controls the telescope's directional pointing encountered difficulties,
    which made matters worse.  Only after a management reshuffling at
    Marshall Space Center, and the addition of more overseers, did the
    project finally get back on track, but with launching delayed until
    late 1986."

The article continues explaining problems that resulted from launching the
telescope from the shuttle to a 380 mile orbit instead of to the originally
planned on 22,300 mile equatorial orbit.  Leading into:

        "Rodger Doxsey, chief of engineering support for the space
    telescope institute, concedes that the delay caused by the Challenger
    disaster was not all bad:  'We were not ready to operate the
    telescope in 1986.  There would have been a big scramble just to get
    it operating.  But that's a route history didn't take.'
        The biggest problem was in developing the computer software
    to control the constantly orbiting telescope:  slewing it into
    position, pointing it to targets and keeping them in the field of view,
    making adjustments dictated by the interference of Earth and the need
    to avoid looking at the Sun. (To prevent damaging glare to the
    optics, the telescope cannot point within 20 degrees of the bright
    limb of Earth or within 50 degrees of the Sun.)   Computers also
    instruct the telescope about which cameras or sensors to operate for a
    particular observation, and which of the many camera filters it should
    use.  The computer must then schedule a time when the resulting data
    can be radioed to Earth through the two tracking and data relay
    satellites, which are not always available, because of commitments to
    shuttle missions and various spy satellites.  Each observation,
    whether for a few hours or several days, must be meticulously planned
    down to the second.  'The entire architecture for this software has
    had to be very much redefined in the last four years,' Doxsey says."

Hank Strub    hbstrub@ucsd.bitnet
Cognitive Science
UCSD, D-015
La Jolla, CA  92093-0515    (619) 534-2541

Human blamed, not the computer! -- jury duty

"Lee S. Ridgway" <>
Mon, 12 Feb 90 13:02:49 EST
Last week I fulfilled one of my civic obligations by complying with a summons
for jury duty - which meant showing up at the appointed time and place, in
order to sit and wait until called or dismissed. [This on the same day the
Commonwealth announced it would file misdemeanor charges against no shows.  But
I digress.]

In Massachusetts, you are called to serve one day or one trial. The one day is
covered by sitting in the jury assembly room, waiting.  Once the one-day /
one-trial obligation is met, you are not supposed to be summoned again for
three years.

In the introductory remarks given by the jury clerk, he admonished us to
stash our certificate of service in a safe place, because it will be the
only sure-fire proof that we did, indeed, do our duty. He continued, and I
quote, "SOMEONE did something to the computer, and so a lot of people
who should not be receiving jury summonses are - sometimes monthly..."

I was struck by the fact that the clerk did not blame the computer for
having messed up the records of who was eligible for a summons and who
wasn't, that he blamed it on a human. And this was a person who,
although articulate, would not normally be thought of as terribly
concerned with such fine distinctions.

Accents are more than just decorations

Kai-Mikael J{{-Aro <>
Tue, 13 Feb 90 10:10:17 +0100
Accents are more than just decorations

The ASCII character set has (obviously) been developed by Americans
for Americans.  This is all very well, but since most nations use
American computers they, too, get to use the ASCII character set.
One consequence of this is that one gets into problems when trying to
display characters not present in the original ASCII set.  What has
been done, then, in most instances is the replacement of certain less
commonly used characters, mainly [\]{|}, with "national" characters.

But this isn't problem-free.  One thing soon noticed is that even
though the characters display as letters on the screen, they are
still by most programs interpreted as non-alphabetics to the
confusion of (not exclusively) novice users.  This also means that
programming languages which use these special characters, C is a
prime example, look strange, to say the least, when displayed with
national characters.

Another problem that soon crops up is that of sort sequence.  Most
languages treat accented characters as letters with decorations, thus
aacute, agrave, acircumflex and so on, all count as a's.  However, in
the Nordic languages the situation is somewhat different.  Aring,
Adieresis and Odieresis in Finnish and Swedish, and their Danish and
Norwegian counterparts Aring, AE and Oslash count as actual letters -
thus they have an alphabetic order of their own.  To further
complicate the matter, this order isn't the same in the different
languages - Finnish and Swedish have ...X Y Z Aring Adieresis
Odieresis while Danish and Norwegian has the order ...X Y Z AE Oslash
Aring.  In spite of this, the decision was taken to use the same
order in all four countries and the Danish/Norwegian order was chosen.

This means that when you sort something alphabetically in Swedish,
all words containing Aring will end up in the wrong place.  If they
end up at all, that is to say - a few years ago I read in the
newspaper that the literary magazine BLM had failed to send out any
issues to subscribers who's name started with Aring.  This was blamed
on "computer error", but a little afterthought gave the realization
that some programmer had used a test like
if ch >= 'A' and ch <= 'Odieresis' then ...
and thought he had handled the entire alphabet.

Eight-bit character sets solve the problem of displaying both
national characters and braces/brackets but they generally don't
solve the problem with different sort orders.

There are then some added complications:
At least in Swedish, V and W are considered to be equivalent, thus
"Walle" comes before "Ville" in a sort.

The Aring has been introduced in Danish and Norvegian very lately, as
a replacement for the Aa-digram.  However, proper names are still
often spelled with aa, and thus aa and aring have to be sorted as if
they were equivalent, but then again, there are foreign words that
contain the combination aa, and these are to be sorted as if they had
tow a's in a row, so one would get "(den) Haag", "H<aring>b",
"Haagerup".  This is probably not very easily done on a computer...

Kai-Mikael J{{-Aro      (
            ^^These are adiereses

Thanks to Mogens Lemvig Hansen for explaining the Danish alphabet to me.

[Parse-ly, Rosemary, Time, Light, Control & Other SAGE Remarks]

"Martin Minow, ML3-5/U26 12-Feb-1990 1023" <>
Mon, 12 Feb 90 07:30:09 PST
(Comments on various postings in Risks 9.67:)

Les Earnest's memoir of SAGE reminded me of a story told by a high-school
buddy who went into the Air Force before college.  He ended up as a technician
at a SAGE installation.  As Les relates, SAGE used a dual-processor system
for reliability: one online, one offline for testing.

One day, the officer in charge stepped out for coffee.  The technicians
switched to the other cpu and started running diagnostics on the system
that had been online.  One of these diagnostics turned on all lamps to
check whether any were burned out.  The officer then came back with a
cup of coffee, glanced at the system he thought was defending America
and decided that the Hour Of Destiny had arrived.  The coffee cup was
tossed aside as he lept to battle stations.  The next day, as my friend
related, a very prominent "ON LINE" sign was added to the system.

My friend also mentioned that the graphics system could be used to display
pictures of young women that were somewhat unrelated to national defense
-- unless one takes a very long view -- with the light pen being used
to select articles of clothing that were considered inappropriate in the
mind of the viewer.  (Predating the "look and feel" of MacPlaymate by
almost 30 years.)  Perhaps Les could expand on this; paying special
consideration to the risks involved in this type of programming.


The discussion of whether the Vincennes' missile control system must obey
"rules of engagement" brings up an interesting problem that has no simple
solution: who is in charge of the technology?  To simplify the problem
somewhat, should the engine control computer in my car allow me to drive faster
than 55 miles per hour?  Should I reprogram that computer when I enter an
Interstate highway or ship the car to Germany?

A few years ago, I was one of the developers of the DECtalk speech synthesizer.
I took some care to make sure that the most common English obscenities were
properly pronounced.  One of my goals with DECtalk was to build a tool that
could be used by a speech-impaired person and I felt that, no matter how
improper the language, it was not my job to restrict the user's expression.

The purpose of a missile control computer is to kill people.  It strikes me as
bizarre to require the computer program to obey international law as well.  Why
should a machine be held more -- or even as -- responsible than the ship's


In Scandinavia, car headlights are to be kept on 24 hours per day.  The local
manufacturers have added relays to shut the headlights off when the ignition is
turned off.  This seems both simpler and more effective than buzzers and
synthesized voices.  Of course, this is technology being used to aid compliance
with the law.


When I started this note, I thought I was commenting on three unrelated
topics.  Apparently, everything is related.
                                                            Martin Minow

Blazers (Re: Woodhead, RISKS-9.67)

Jeff Berkowitz <jjb@sequent.uucp>
11 Feb 90 17:24:49 GMT
    Robert J Woodhead writes:
>Fortunately for many of us, after about 40 years of intense debate in the
>automotive industry on this complex and challenging "lights on" problem, some
>manufacturers are adding a simple device that alerts you if your lights are on
>when the ignition is off.  These range from a simple analog "BReeee!"  in my
>Chevy Blazer...

I have a Blazer (actually a GMC Jimmy, the same vehicle) with the "analog
BReeee!" feature referred to by Mr. Woodhead.  I won't disagree that the
buzzer is a nice feature.  The observed rate of "battery dead due to lights
on" with this vehicle, however, is higher than any other vehicles we have
ever owned (two occurrences in 18 months).

The problem is caused by a small convenience light located on the ceiling
of the vehicle just inside the rear cargo compartment door.  The light
housing includes a rocker switch, which requires very low pressure to
operate and is aligned axially rather than longitudinally.  The switch
is therefore easily operated by accident.  The act of lifting a grocery
bag from the rear compartment can cause the lip of the bag to move the
switch, for example.

This tiny light is NOT coupled into the manufacturer's "beeper system",
of course - that would be too annoying.  The light is very faint, so
faint that one can fail to observe it when peeking into the garage at
night.  We believe that about three days of continuous operation of
the light are sufficient to drain the battery to the point that it
will not start the car (we're not sure about this, since we never
really know when the switch was thrown as we scurry around, days later,
connecting jumper cables :-).

To my mind, this is an excellent "microexample" of how a complex system
design can fail miserably to achieve the intent of the designer.  Although
this system is not computerized, it contains an obvious message: reliability
can't be glued on.

Jeff Berkowitz N6QOM            uunet!sequent!jjb
Sequent Computer Systems        Custom Systems Group

Re: Computers, good and evil (Sicherman, RISKS-9.67)

Fri, 9 Feb 90 10:29:41 EST
>  "Apple pie is in itself neither good nor bad; it is the way it is used...

I have read none of the works on this topic, but (unless I am thoroughly
confused) it seems that McLuhan's apple pie analogy is a somewhat sarcastic
attempt at supporting his argument that technologies (and apple pie) do
have inherent qualities or a "nature" which renders them "good or bad" of
their own.  Apparently he feels that the "nature" of apple pie is good, and

Certainly he could not infer such a quality unless he liked apple pie,
something which is obviously not true for all people.  In fact, for those
allergic to apples, the nature of apple pie is, if anything, bad.  And so
he has succeeded in proving the very point made by Sarnoff.

Gregg TeHennepe                        | Minicomputer Specialist
gateh@conncoll.bitnet                  | Connecticut College, New London, CT

Telephone Switch Security

Roland Ouellette <>
Mon, 12 Feb 90 19:36:28 CST
Lately there has been little lack of discussion about reliability of
telecomunications systems.  I have also seen several articles which
discuss the security of the same systems.  MIT has recently installed
an ISDN system using a #5ESS system.  There has been a whole lot of
discussion about what the system can and cannot do.  October '89's
issue of Technology Review has an article entitled "The Twilight
Phone."  In February's issue there is an editorial and two replies.

The editorial claims that it is possible to use the phone system to
bug rooms.  The replies claim that, while theoretically possible,
getting the switch to do that would require programming expertise and
physical access to the switch.

There then is the possibility that folks in charge could order the
owners of the switch to bug a room.  This is more invasive than a
normal wire tap, because the phone's microphone could be left on all
of the time.

Then there is this article which appeared in the WSJ.  It does not
state how said hackers "entered the company's computer," but it makes
me wonder.  I'd be interested to hear how these calls were rerouted.

    Hackers - Accused of scheme against BellSouth. Legion of Doom group.
        {The Wall Street Journal, 8-Feb-90, p. C20}

    Federal  grand juries  in  Chicago and Atlanta   indicted four alleged
    computer hackers in what authorities called  a fraud scheme that could
    potentially disrupt emergency "911"  telephone service throughout nine
    Southern states.  The men, alleged to be part of a closely  knit cadre
    of computer hackers known as the Legion of Doom, gained access  to the
    computer system  controlling telephone emergency  service of BellSouth
    Corp.,  the Atlanta-based    telecommunications  giant.  The   Chicago
    indictment   said   members of the  Legion   of  Doom are  engaged  in
    disrupting  telephone    service  by entering  a   telephone company's
    computers and changing the routing of telephone calls.  The hackers in
    the group  also fraudulently obtain money from   companies by altering
    information in their computers,   the indictment  said.  The   hackers
    transferred stolen telephone-computer  information from  BellSouth  to
    what prosecutors   termed a  "computer   bulletin  board  system"   in
    Lockport, Ill.  In turn, the men planned to  publish the computer data
    in a hacker's magazine, the grand jury charged.

Roland G. Ouellette

Please report problems with the web pages to the maintainer