The RISKS Digest
Volume 4 Issue 31

Wednesday, 17th December 1986

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Don't sit too close! ("And Now, Exploding Computers")
Jerry Leichter
Car-stress syndrome
Robert D. Houk
Korean Air Lines Flight 007
Niall Mansfield
Heisenbugs
Rob Austein [an example]
Doug Landauer
Criminal Encryption
Bill Gunshannon [counterexample?]
Taking the "con" out of econometrics... correction and a plea
Mike Williams
Info on RISKS (comp.risks)

Don't sit too close! ("And Now, Exploding Computers")

<LEICHTER-JERRY@YALE.ARPA>
17 DEC 1986 16:48:51 EST
From the New York Times (17-Dec-86):

    And Now, Exploding Computers

...[T]wo owners of Compaq Portable II computers were rudely surprised recently
when their machines simply blew up.  The problem, said Jeff Stives, a spokes-
man for the Houston-based company, arose when service technicians improperly
rewired the battery circuits on the computers' main circuit boards.

Compaq engineers managed to blow up another computer in the tests, thus con-
firming the problem.

In each case the explosion, caused when the machine's lithium battery is acci-
dentally drained of energy and then re-energized by the computer's 5-volt
power supply, was strong enough to break the case of the computer but not
potent enough to shatter the glass of the built-in video display screen.  No
injuries were reported.

Owners of Compaq Portable II computers that have had repair work done on the
system board are advised to call Compaq at (800) 847-5785, or call their local
dealers for free inspections.
                            — Jerry


Car-stress syndrome

Robert D. Houk <Houk@RIVERSIDE.SCRC.Symbolics.COM>
Wed, 17 Dec 86 18:42 EST
From "car" magazine (FF Publishing, 97 Earls Court Road, London W8 6QH),
December 1986 issue, "ORACLE" column, page 72

  Electronics are quickly becoming the star of the high-tech society. But they
  are not without problems. The electromagnetic waves generated by electronic
  equipment are causing concern among health professionals. Cars are no
  exception and Professor Kazuo Suenaga of Kurume University has for the first
  time found scientific proof that electromagnetic waves generated by a car's
  engine are the cause of car-stress syndrome. According to his findings, such
  waves from the spark plugs cause nervous stress in the driver and reduces
  alertness. A device called the Neutral Auto which oscillates
  micro-electronic waves prevents hazardous electromagnetic waves from
  entering the passenger compartment, and is said to be effective in
  preventing motion sickness.

Passed along, with my personal comments pre-censored out.  (Actually, the
"preventing motion sickness" is conceivable, but the rest sounds rather
flaky to me, even allowing for the difference in language 'tween England and
the USA.)  It would be interesting to see the original paper/report
(unfortunately not cited in the column) - maybe someone else out there is
familiar with the un-aforementioned paper or Professor Suenaga/Kurume
University???


Korean Air Lines Flight 007

Niall Mansfield <MANSFIEL%EMBL.BITNET@WISCVM.WISC.EDU>
Wed 17 Dec 86 10:44:43 N
In RISKS-4.26 Steve Jong, basing his discussion on Seymour
Hersh's  "The Target is Destroyed" (1986), said:-

> [it was] concluded that a combination of human errors caused the 
> navigational snafu.  One of the errors was postulated to be a well-known 
> blind faith in the plane's inertial navigation system (INS).  
> 
> ... the gist of it that a crew member fat-fingered the "you are here" 
> coordinates.
>    ... if the KAL crew looked at their radar and saw the Kamchatka 
>    Peninsula where there should have been open ocean, they probably 
>    shut off the radar, because the INS was functioning normally.

Even though Peter Neumann did note that other books have different views on
what happened, I think one of the other possible explanations, which
exonerates the computers, should still be mentioned.

Very much in contradiction of the quoted arguments above, R.W.Johnson in
"Shootdown - the verdict on KAL 007" contends that the plane did not have
any INS trouble. Rather, the crew filed flight plans at Anchorage which
showed pencilled-in modifications to the computerised flight plan, and that
007's actual course agreed with this modified plan.  (Johnson reproduces
copies of the plans, which apparently were included in the International
Civil Aviation Organisation's report).


Heisenbugs

Rob Austein <SRA@XX.LCS.MIT.EDU>
Wed, 17 Dec 1986 02:03 EST
The recent discussion on Bug Taxonomy reminded me of this one.  I may
have mangled some of the incidental details, but the gist is gospel.

We have this ITS machine called MC.  Its purpose in life is to provide
a place to put the big mailing lists for the MIT CS labs so that the
other lab machines aren't driven into the ground by the load the
mailer puts on the processor.  So we tend not to use MC for much else,
and COMSAT (the mailer) usually has the machine to itself except when
the maintainers are changing something.

Enter a curious hacker who wants to know why MC has not processed any
mail for the last 36 hours (this was a holiday weekend, or somebody
would have noticed it much sooner!).  He pokes around the mail queue
directory, checks to see if the filesytem is full, the net is hung,
any of the normal things.  Finds nothing odd.  Finally he examines the
COMSAT job with the PEEK program (like TOPS-20 SYSDPY unix ps).  Lo
and behold, the COMSAT job is now running, the mail queue is being
processed, and except for the gap between timestamps in the telemetry
file there is no evidence that this ever happened.

After much head scratching amongst the COMSAT and ITS maintainers, we
figured out what had (probably) happened.  It seems that COMSAT was
stuck in a system call, probably doing some network I/O; there was a
bug in the code for that system call which caused it to hang forever
instead of returning some kind of failure condition.  Certain
operations involved in examining another job (with PEEK or any other
program) cause the examinee to experience a context switch if it is in
the middle of a system call: the program counter gets set back to user
context, the user context page map and registers are restored, and so
forth.  This kind of involuntary context switch is a normal event on
ITS, and great pains are taken to make it invisible to the user code.
Among other things the program counter and any memory locations that
are modified by the system call are updated so that the interrupt is
transparent and the job can proceed as if nothing had happened.

So the act of looking at COMSAT broke COMSAT out of the losing system
call, and when it restarted the system call it exited properly with an
error condition (not surprising, since the machine on the other end of
the network connnection presumably had hung up the phone 35 hours and
55 minutes ago).

Did I hear somebody mention the Uncertainty Principle?

--Rob


Heisenbugs

Doug Landauer <landauer@Sun.COM>
Wed, 17 Dec 86 12:19:20 PST
In the rest of the world (most of us don't get to retry our operations on
backup processors), Heisenbugs is already a fairly common term — it refers
to bugs which go away as soon as you try to run them under a debugger (or
with the debugging compile- or run-time flags set).


Criminal Encryption

Bill Gunshannon <bill@westpt.UUCP>
17 Dec 86 13:44:24 GMT
In his Item 2 (in RISKS 4.26) David Fetrow mentions an incident from a few
years ago about a man arrested for kid-porn and the hacker who "broke" his
encrypted file for the courts. I think it is time that we finally laid to
rest the notion of all these 12 year old hackers out there who are more
powerful than a Cray XMP. The article also was printed in TIME magazine and
even rated nearly a full page with a photograph of the hacker as well.  The
fact of the matter is nothing on the disk was encrypted and what the hacker
did was public information and being done by micro-computer users all over
the country. An explanation follows.

The file the court was interested in was not encrypted, it was password
protected and as you might expect the defendant was not likely to freely
give them the password. At this point for reasons I can't even imagine
they brought the hacker in to the case. 

For more background information the computer was a Radio Shack Model III.

Here is an example of a dump of a directory of a disk I created for this
demonstration:

            file      file name & extension
location  attributes        in ascii
on disk      \/                \/
  \/   |            |                         |
110B00: 0000 0000 0000 0000 0000 0000 0000 0000 ................
110B10: 0000 0000 0000 0000 0000 0000 0000 0000 ................
       |    |    |                             |
          ^    ^                ^
          |    |                |
          |    |       Hash Index Table(HIT)
          |    |
          |    User Password
          |
          Owner Password

110B00: 1000 0000 0046 494C 4532 2020 2044 4154 .....FILE2   DAT
110B10: E042 E042 0000 FFFF FFFF FFFF FFFF FFFF .B.B............

110240: 1000 0000 0046 494C 4531 2020 2044 4154 .....FILE1   DAT
110250: 9642 9642 0000 FFFF FFFF FFFF FFFF FFFF .B.B............

There are two passwords for each file, a "owner" password and a "user"
password.

The file named "FILE1   DAT" is not password protected.
The file named "FILE2   DAT" is password protected.

A quick look at the directory entry for each file shows you the location 
of the passwords in the entry. The passwords are not really encrypted.
They are merely hashed. This allows an 8 character password to be stored
in 2 bytes(1 word on this machine). It also means that any given 8 letter
combination will always hash to the same value. The entry for no password
is 8 spaces(ASCII 32). All that means is by changing the entry for the
"owner" and "user" passwords on "FILE2   DAT" to the same thing as you see
for "FILE1   DAT" you have effectively removed the passwords.
This information was provided in numerous magazines like "80 Micro" and
"Kilobaud" which had wide readership in the early days of microcomputers.
The reason the information was provided was because companies like Tandy 
and Microsoft distributed their software on single sided disks which was
what a store bought Radio Shack computer had in it. But most people(read
hackers) who used their machines seriously had modified them to use 80
track and double sided disks. Because of passwords that were not published
it was impossible to just copy such as Microsofts Fortran Compiler onto
another disk. With the release of this information all one had to do was
remove the passwords and copy the files to any media desired.

As you can see there is nothing spectacular about what was done. It was done
a regular basis in homes all across the country. But what I see as a problem
and why I think this information is applicable to RISKS is that it got so
much coverage in the press and served to take a large group of the public 
who are already uncomfortable or afraid of computers and their effect on day
to day life and fed the fires. Here we are 2 years later and this story is
still showing up and what is worse is that it will become more fantastic
in time as the facts become less and less known. There was no mention of
encryption in the TIME article. But as you can see with encryption being
on everyones mind today the story has gone from "boy breaks password" to 
"hacker breaks encryption". 

bill gunshannon

UUCP:      philabs!westpt!bill               PHONE:     (914)446-7747
US SNAIL:  Martin Marietta Data Systems      RADIO:     KB3YV
           USMA, Thayer Hall                 AX.25      KB3YV @WA2RKN-2
           West Point, NY  10996


Taking the "con" out of econometrics and computer modeling:

"John Michael (Mike) Williams" <JWilliams@DOCKMASTER.ARPA>
Wed, 17 Dec 86 14:55 EST
          a correction and a plea
To:  risks@CSL.SRI.COM

In RISKS-4.28, Craig Paxton, identified as an economist from Northwestern
University, observes that "E. Leamer" is the correct spelling of the UCLA
economist's name, not the "Edward Learner" I used.  I double-checked the
Science article, and discovered, with the aid of a co-worker, that it is
indeed "Leamer," something my increasing far-sightedness could not
distinguish in the proportionally-spaced Science typefont:  "rn" and "m"
continue to look alike through my (obsolete) prescription.

My apologies to Professor Leamer, Science, and the RISKS readership.
Despite considerable effort on my part (and the moderator's), an error
got through that was caught, finally, by peer review.

Professor Paxton compares this "subtle error" to those in economic
verification.  No one can consider the 91% error rate measured for modeling
of short term oil price changes a subtle error, especially in models sold to
or used by the Government to influence major economic policy.  A stopped
clock is not subtle.  Bob Estell, in RISKS-4.25, has it right when he
suggests the ACM, IEEE, et al. should require supporting data be archived
and retrievable, even if not published with the article in question, so that
peer reviewers may at least have some basis for determining reproducability,
much less validity or error rate.

In fact we in computers should help pioneer such archives for scientific
validation and peer review generally, since initial publication itself
is increasingly a computer-based enterprise.  RISKS, but for lack of
referees, is a prototype of the future journal whose articles must be
assessed, reproduced, validated, and archived.

The proprietary arguments do not impress me:  if there are those who
wish to hide their methods in the name of profit, then they needn't
publish in scientific journals, nor expect scientific endorsement.  Let
them make a fortune, but let them be regarded with the same skepticism
that authors of "Get-Rich-Quick" books and newsletters are:  if you're
so smart [about money, economics, etc.], how come you ain't rich?  How
come you're peddling books, or models, instead of profiting from the
contents thereof?

I believe there are many ACM, IEEE and other society officials who are
regular readers and sometime-contributors to RISKS:  may we hear from them?

     o First, have they sampled their own publications, as the Journal of
Money, Credit and and Banking was, to find what percentage of findings, in
computer modeling or otherwise, were reproducible?  Do they have policies
about surrender of data, equations, etc.  on peer request?  Do they find the
falsification of data and experiments plaguing the biomedical community at
the moment to be a problem in computer science publications?

     o What actions will they take against authors/papers/presenters who
refuse to supply information for reproduction, or validation, or who have
falsified, stolen, or otherwise misapplied data and/or findings?  What
policies do they have on authorship of papers, and are its journals free of
the misrepresentations of the number, contribution and even identity of
authors, so serious in other fields that even the Wall Street Journal of
last week had a front-page story on this problem in AIDS research?

     o What is their comment on the challenges for reform in my article
in RISKS-4.21, and the additional suggestions by Estell noted above?

Let me ask the readership to forward copies of this discussion to those
officers of societies they may know, who are, or should be, able to set
or adjust policy on these matters.  As a member of ACM since 1964, and
in correspondence with an ACM Committee, I would expect at least a
comment from ACM as a society.

Please report problems with the web pages to the maintainer

x
Top