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 5 Issue 10

Thursday, 9 July 1987

Contents

o Firebird computer story
Paul Kalapathy
o COMPUTER CLUBS FOOT
Anthony A. Datri
o Re: 7 Inmates Escape; Computer Blamed!
James Lujan
o Sprint access code penetration (catching the baddie)
Darrell Long
o US Sprint and free long distance
Eric N Starkman
Edward J Cetron
o RE: BIG RED
Eugene Miya
o Risks of battery disconnections
Steve Mahan
o Japanese simulation design
Sean Malloy
o Hardware failures and proofs of correctness
Rob Aitken
Michael K. Smith
o Info on RISKS (comp.risks)

Firebird computer story

Paul Kalapathy <convex!paulk@a.cs.uiuc.edu>
Thu, 9 Jul 87 09:30:23 cdt
   I have a friend, Mike* (not his real name), who owns a 1983 Firebird.
He does a great deal of work on cars in his spare time, but his education
and job are in computer science.  The work that he generally does is in
microcomputers and microcontrollers.  Mike was interested in improving the
performance of his Firebird, and happened to have a friend John* (not his
real name, either) who worked for GM and had access to the design and 
coding for the car computers.  John was willing to provide this information
to Mike as a personal favor, and did so.

   There is a PROM in the car computer that contains the basic parameters
of the engine's operation, such as fuel mixture, ignition advance, temperature
compensations, etc.  If I remember correctly, the PROM is a type which is
pin compatible with an industry standard EPROM (i.e., the EPROM can be
programmed and inserted directly into the PROM position by changing only
one or two power supply pins).  The information in the PROM is not necessarily
set for the highest engine performance, but rather to meet federal emissions
control and fuel economy regulations.  Therefore, changes in the parameters
in the PROM could substantially improve the engine performance, to the
detriment of compliance with federal regulations.

   Mike proceeded to replace the PROM with an EPROM of his own programming.
This resulted in a considerable improvement in the performance of his
Firebird.  After making this modification and adding exhaust headers to the 
car, it had a top speed in excess of 150mph. (After reaching 150mph on an
interstate highway, Mike decided he really didn't want to know what the
top speed was.)  I don't recall what the top speed was before these 
modifications, but it was a good deal closer to 100mph than 150mph.  


* "John" does not wish to be harrassed by his employer.  "Mike" does not wish
  to be harrassed by the government for modifying polution control on his 
  car.


COMPUTER CLUBS FOOT [DIGITAL MASSAGE?]

Anthony A. Datri <aad+@andrew.cmu.edu>
Thu, 9 Jul 87 19:10:34 edt
One risk of computers that I haven't seen addressed in this forum is the
risk of having your cpu fall on you.  This comes from a man who several
months ago had the experience of an 11/45 falling on his foot.

anthony a datri      cmu computer club


Re: 7 Inmates Escape; Computer Blamed!

Jewel <jwl@lanl.gov>
Thu, 9 Jul 87 10:17:49 MDT
The information concering the kidnapping, shooting, and release of the 6
other inmates is correct, however the rest of the information is misleading.

The guard tower was being staffed only during daylight due to financial
restrictions at the time of the escape.  Now it is being staffed 24 hours a
day.  Although the guard tower was unmanned at the time, it was not in the
field of view where the prisoners scaled the fence.  That area of the fence
was being monitored by motion detector sensors which were attached to a
computer system.  Due to several false alarms, it was decided to disable
that portion of the monitoring area until the problems were solved.  Also,
the fence was NOT topped with the normal razor that surrounds the rest of
the fences.  The escape area was still under construction.  The 18 foot high
chain-link fence was also not covered with a fine mesh fence which made
climbing the chain-link fence trivial.  Normally, the fine mesh makes it
near impossible to get a good hand or foot hold on the fence.  It has also
been mentioned that there are some design flaws in the computer surveillance
system as well as the fence enclosure.

The combination of weaknesses is what made the escape possible.  At present,
only one inmate has been recaptured the other six are still at large, and are
suspected of traveling south towards Mexico.  Recent sitings have confirmed
this suspicion.
                             James Lujan (aka Jewel)


Sprint access code penetration (catching the baddie)

Darrell Long <darrell@sdcsvax.ucsd.edu>
Thu, 9 Jul 87 15:04:32 PST
I know (personally) of one case where one of my ex-students decided that he
needed free long distance.  He would use his Apple-II (it was some time ago)
to dial up the local number and try some number as an access code.  He
called the school's computer, so he knew that if he got a carrier then he
had gotten through.

To make a short story even shorter, he used sequential probing to choose the
access codes.  The long distance company's computer (it wasn't Sprint, he'd
gotten away using their's for a long time) picked up on the sequential probing.
The next thing he knew there were police wandering around his house late at 
night.  A week later he was arrested and his computer taken away (what a
terrible punishment!).

The funny thing was Pac-Bell was after him to give them his "source" and find
out where he had gotten the sophisticated algorithm, etc.  It seems they
thought he was a big time phone cracker.

Darrell Long                                       UUCP: darrell@sdcsvax.uucp  
Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093
Operating Systems submissions to: mod-os@sdcsvax.uucp


US Sprint and free long distance

Eric N Starkman <ens@ATHENA.MIT.EDU>
Thu, 9 Jul 87 12:06:47 EDT
    I was reading the Wall Street Journal last week, and noticed a
full page ad for the new US Sprint "FON Card."  The ad included a
picture of a sample card.  I tried making a US Sprint call using that
card number, and it worked.  Further investigation revealed that ANY
fourteen digit number would allow calls to be completed.

    In this case, the problem was fixed by the next afternoon.  But
Sprint is not always so prompt.  I once called them to request deactivation
of a code, telling them that the security of the code had been compromised.
They told me that it would take at least a week to deactivate the code.

    US Sprint and the other companies claim to lose a lot of money
from theft, but they are evaluating those losses based upon the retail
value of the unauthorized calls.

    It is only reasonable to use retail value for calls that
people would have paid for otherwise.  Most people I know who (would)
use unauthorized long distance codes would use them only for calls
which they would not have made otherwise.  The real cost of the
unauthorized codes, then, is simply the long distance company's
marginal cost, which is negligible.


Sprint access codes (Re: RISKS DIGEST 5.9)

Edward J Cetron <cetron@cs.utah.edu>
Thu, 9 Jul 87 22:15:30 MDT
    The fact that the Florida gentleman received such a large bill without
warning is quite suprising.  Recently, my sprint access code made its way
to a similar hacker's BBoard.  Within days, US Sprint called me, told me what
had happened and that they were actively tracking (tracing?) the sources of
the phone calls.  Seems that they computer systems automagically picked up on
calls being made very closely spaced in time from many different cities and
that they did not fit out 'usage pattern'.  When my bill came out (all 30 pages
worth) there was a nice letter saying to 'just pick out the calls you KNOW are
yours' which was easy since my calls all originated in Salt Lake City. 

    They specifically wanted the access code left live until they could
try to track down the callers who were using it.  They just called the other
day and informed me of the new number and that of the several thousand dollars,
they had recovered a great deal of it....All in all, they did a good job of
keeping the customer happy and well informed, and impressed me with the 
capabilities of their software to extract features that indicate abuse.

-ed cetron


RE: BIG RED

<eugene@ames-nas.arpa>
09 Jul 87 10:49:20 PDT (Thu)
>... has eluded foreign experts.  The so-called virus has been held responsible
>for a string of computer disasters in several countries since it was first
>detected in a NASA system in the United States in 1985.

This is news to me (unless it's a mix-up with another incident).  I would
appreciate any evidence to elaborate.  [Location, system type, etc.]

--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
  {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene


Risks of battery disconnections

Mahan <steve@ncsc.ARPA>
Thu, 9 Jul 87 15:24:47 CDT
     In reference to the reason for disconnecting the negative terminal of a
car battery:  Have you ever touched (accidentally) the frame or sheet metal
with a wrench while disconnecting the positive terminal?  

     Disconnecting the negative (ground) terminal first is a safety precaution
for the mechanic to avoid inadvertantly shorting the battery to ground.  After
the negative terminal is disconnected the positive terminal may be brought into
contact with the frame without ill effects.
                                                steve
Steve Mahan, Naval Coastal Systems Center, (904) 234-4224.  
Standard disclaimer applies.


Japanese simulation design

Sean Malloy <malloy@nprdc.arpa>
Thu, 9 Jul 87 11:53:36 PDT
> From: <PRITCHAR%CUA.BITNET@wiscvm.wisc.edu>
> Subject: BALANCE OF POWER
> Note that 45 years ago, the Japanese war-gamed their intended attack...

There were several Japanese simulations of the attack on Midway. The
first simulation took into account the Japanese forces, the American
forces, relative skill levels, and the like. The simulation was
played, and the result of the simulation was that the Japanese lost.

This was unacceptable to the admirals, since they knew that they had a
superiority in force strength, better intelligence, and the advantage
of surprise, so they ordered the rules of the game to be redesigned.
After a couple of iterations, playing the simulation produced a Japanese
victory in line with what the admirals expected from their plans.

The attack was carried out according to the final simulation,
whereupon the accuracy of the initial simulation was proved, with the
Japanese losing most of their carrier force and being unable to
conduct a landing on Midway.

Sean Malloy, Naval Personnel Research & Development Center, San Diego, CA, 
  92152-6800   (VOICE)  (619)225-6434        (soon to be malloy@nprdc.mil)


Re: Hardware failures and proofs of correctness

Rob Aitken <aitken%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
9 Jul 87 5:58 -0800
In Risks 5.8 Don Chiasson notes the problem of hardware bugs, and makes the
statement "it is not possible to prove the correctness of hardware". This is
only partially true. A group at the University of Calgary has recently
proven the correctness of a chip design and is continuing research in the
area. (Anyone interested in the references can send me mail, although I add
that I am not associated with this group). As for the testing of chips once
the design has been verified, Mr. Chiasson is on target, as the majority of
testing schemes attempt to minimize the number of defective chips released,
rather than ensure that all are fault-free.

Rob Aitken   Alberta Research Council, Calgary AB
UUCP: ...{utai,alberta,ubc-vision}!calgary!arcsun!rob


Hardware failures and proofs of correctness

Michael K. Smith <CMP.MKSMITH@R20.UTEXAS.EDU>
Thu 9 Jul 87 13:30:33-CDT
In response to Don Chiasson's 6 July 87 comment "it is not possible to
prove the correctness of hardware".  Clearly exhaustive testing is not a
practical means to accomplish this.  But see:

  Hunt, Warren A. Jr., "FM8501: A Verified Microprocessor", Tech.
  Report 47, Institute for Computing Science, University of Texas, Austin
  78712, February 1986.

This is Warren's dissertation and describes the formal specification and
definition of a microprocessor (similar in size and complexity to a
PDP-11) and provides a proof that the formal definition satisfies the
specifications.  Essentially a set of mathematical operation are defined
that describe the specification of the machine and these operations are
shown to be equivalent to a graph of hardware gates.  The mathematical
operations are characterized by commonly used functions, such as
addition, subtraction, and shifting.  The implementation (gate graph) is
characterized by Boolean functions applied to components of bit-vectors.
The machine was specified and defined in the Boyer-Moore Logic and the
proof was done using the Boyer-Moore Theorem Prover. 

A brief, but more readily available description can be found in Bevier,
Hunt, and Young, "Toward Verified Execution Environments", in Proceedings
1987 IEEE Symposium on Security and Privacy, April 1987.

This work is currently being continued at Computational Logic Inc.

- Michael K. Smith 

Please report problems with the web pages to the maintainer

Top