RISKS@CSL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (06/27/87)
RISKS-LIST: RISKS-FORUM Digest Friday, 26 June 1987 Volume 5 : Issue 6
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Hardware vs Software Battles (Mark Brader, Guest RISKS Editor)
What the world needs now ... (Jonathan D. Trudel, Rick Lahrson,
WIlliam Swan, Karen M. Davis, Henri J. Socha, Stuart D. Gathman,
Peter DaSilva, The Sentinel, David Phillip Oster)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
FTP back issues Vol i Issue j from F4.CSL.SRI.COM:<RISKS>RISKS-i.j.
Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).
----------------------------------------------------------------------
Date: Thu, 25 Jun 87 22:18:40 EDT
From: msb@sq.com (Mark Brader)
To: risks@csl.sri.com
Subject: Hardware vs Software Battles (from Usenet)
[I have selected the following articles from a long discussion in the
Usenet newsgroup comp.misc. My interpolations are marked like this.
I have deleted some header lines, some text, and all signatures.
--msb (Mark Brader)]
[TNX. Although Usenet readers may already have been saturated
with this material, the VAST MINORITY of remaining readers in
the rest of the net world also deserves to see it. PGN]
------------------------------
From: trudel@topaz.rutgers.edu (Jonathan D.)
Newsgroups: talk.bizarre,comp.misc
Subject: What the world needs now
Keywords: Originally from a friend
Message-ID: <12067@topaz.rutgers.edu>
Date: 18 May 87 19:01:57 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
... is a piece of software that actually makes a computer blow up just
like in the movies. This is long overdue. "Lay" people are extremely
disappointed when a program or system grinds/wheezes to a halt with some wimpy
message like "B037X: USER ERROR IN GAPX TABLE" or "CATASTROPHIC SYSTEM FAILURE:
BUFFER OVERFLOW INDICATOR OVERFLOW" or "Bus error - core dumped". They want
to see explosions! Paper spewing out from wherever paper spews out from!
And gicky fluid oozing out of the machinery as the entire machine room
collapses onto itself because someone either forgot to put a %*&#*$#&@ in
column 92 or asked the computer an impossible question like "What's the
meaning of life?", "Why?", "CAN you get there from here?", "Calculate pi to
the last digit" [THAT'S NOT A QUESTION!], or "Where's the bathroom?" That's
a worthy goal for computer technologists everywhere. Forget artificial
intelligence! Forget relational databases! Forget distributed network
architecture proposal interface protocols! Forget documentation! Forget
associative memory! Let's make computers explode in our lifetime!!!
----------------------
[So how do you shut down a computer with no HALT instruction, *without*
requiring hardware repairs? Like this... --msb]
From: rick@oresoft.UUCP (Rick Lahrson)
Message-ID: <37@oresoft.UUCP>
Date: Mon, 25-May-87 02:52:46 EDT
Organization: Oregon Software, Portland OR
A small step was taken toward this end back in the early sixties, in IBM's
System/360 model 30 CE school. Seems one of the better students had time
enough to pore over the schematics and discover which cores (remember core
memory?) were located just beneath the overtemp sensor. He wrote a small
program that did nothing but abuse those particular cores by writing ones
and zeroes alternately to them, until they heated up, and the temperature
sensor shut down the machine.
First, of course, the program printed out "Programmed Power Down" on the
console. Caused a lot of bewilderment among the students and instructors.
Especially since the big feature being touted about the S/360 was that it
was so oriented to multiprogramming that it didn't even have a HALT
instruction.
----------------------
[Then there was a string of articles (actually, this may have been a sep-
arate discussion in misc.misc, but what the heck, it fits in nicely here),
pointing out that a number of modern computers have a software-handled
OFF switch, and have to have their plugs pulled when they get totally
stuck. These articles were then nicely topped by this one: --msb]
From: bill@sigma.UUCP (WIlliam Swan)
Message-ID: <1261@sigma.UUCP>
Date: 19 Jun 87 16:35:12 GMT
Organization: Summation Inc, Kirkland WA
Some years ago I worked on a battery-powered instrument (it would run 24 to
48 hours on batteries) in which the project manager insisted that the OFF
switch should be an interrupt to the CPU, which would then power itself
down.
You guessed it.. the uP derailed and the only ways to get it back were:
1. Open the instrument up and yank the battery leads, or
2. Pull it off the charger and wait a day or two.
Fortunately (:-) it never made it to market.
----------------------
[This one must be the most devastating for a computer victimized by it.
Imagine being the person who set it off by accident! --msb]
From: kmd@sdcsmb.UUCP (Karen M. Davis)
Message-ID: <424@sdcsmb.UUCP>
Date: Fri, 22-May-87 11:47:38 EDT
Organization: System Development Corporation, Santa Monica CA
Um.... many computers built for military applications contain a "trap door"
that can be reached by an assembly sequence that will direct the transformer
or power supply *input* onto the motherboard. Manufacturers of this type of
computer include HP and Litton. This "feature" is supposed to be used to
destroy your computer as the installation is being overrun by the enemy.
Since most of these suckers use large DC generators as input to the
transformers/power supplies, you can imagine the fireworks that occur when
this stuff reaches all those cute little ICs. ;-)
It was supposed to leave the attackers with molten sludge.
----------------------
[There were a number of poorly documented articles about walking disk
drives and "halt and catch fire" instructions, but the following ones
seemed sufficiently well described to include here. Some relate to
deliberate actions, but in every case there is the question, "what if
this happened by accident?" --msb]
From: socha@drivax.UUCP (Henri J. Socha (x6251))
Message-ID: <1827@drivax.UUCP>
Date: 11 Jun 87 18:59:22 GMT
Organization: Digital Research, Monterey
The following story was related to me by employees of
I.P. Sharp Associates (IPS). They, with Scientific Time
Sharing Corp. (STSC) wrote APL for IBM back in the early days.
It seems that there started to be competitors to IPS/STSC's APL system.
These companies would usually use IBMs APL (written by IPS/STSC)
on their large IBM mainframes. Sometimes they would add extra
bulletproofing so that APL would not bomb, get better performance, etc.
Now, IPS/STSC really knew APL (and the IBM implementation) very well.
In fact, an employee living in Palo Alto would debug/enhance the
production on-line APL system from his home!
There were people across North America and in Europe (at that time) using
this single mainframe (360/158 I think). The computer was in Toronto Canada.
Anyway, a competitor named Manhattan APL (I think) called up IPS and said
they were about to come online and if IPS wanted to, they could test
the system. Manhattan said they had filled in all the holes and the system
was unbreakable.
Manhattan APL came online for their customers about 2 months late.
It seems that some of their disk drives had thrashed themselves to death.
----------------------
From: stuart@bms-at.UUCP (Stuart D. Gathman)
Message-ID: <402@bms-at.UUCP>
Date: 28 May 87 19:02:14 GMT
Organization: Business Management Systems, Inc., Fairfax, VA
I inadvertently wrote a BASIC program on an HP2000 at George Mason University
that blew up the disk drive. It was an 8 player real time space war game.
The problem was that all interprocess communication had to take place via
disk. I used the documented LOCK function for serialization. It seems that
this function loaded a special OS overlay whenever invoked and reloaded
the file I/O overlay directly afterward. With 8 programs doing this
as fast as possible, the disk would die.
The problem was solved by using an undocumented feature of the scheduler.
A process was always assigned 1 sec of CPU following completion of a wait
for terminal I/O. This allowed serialization with careful coding while
not using the LOCK overlay.
BTW, an IBM PC program can blow up the monitor and video cards by programming
nasty parameters into the video controller chip.
----------------------
From: peter@sugar.UUCP (Peter DaSilva)
Message-ID: <152@sugar.UUCP>
Date: 10 Jun 87 13:08:32 GMT
Organization: Sugar Land UNIX - Houston, TX
The CompuColor 2 personal computer of about the 1978-80 era could be made
to fry itself from BASIC. A simple FOR loop outputting 1-255 into a certain
I/O address (it's Z-80 based) caused the screen to blank in an entertaining
fashion, followed by the smell of smoke. You had to pull the plug at the
wall to get it to stop. I was totally amazed. Just think of the possibilities.
I don't know exactly what was going on, but I suspect that they had too much
trust in software and used the CPU to control such things as the power supply
so they could save $5 worth of chips.
----------------------
From: sentinel@killer.UUCP (The Sentinel)
Message-ID: <913@killer.UUCP>
Date: Wed, 20-May-87 20:30:14 EDT
Organization: A Un*x Box in Texas
When I was in high school, we had several SWTPC 6800 machines, of
slightly post-Altair vintage. They had 32k of RAM (a lot at the time),
5-1/4" single density drives that held around 90k, a CP/M-like operating
system, and you had to boot them by calling the disk boot rom from the
monitor.
Anyway, I saw demonstrated (not with the school's permission, as you can
probably guess) a program called "DEATH" which did a number of destructive
things including stepping the drives out of range and apparently using this
opcode you mention. I remember the main board going in for service after
that and coming back with lots of new chips. I never knew how a program
could do this until now...
(Don't take everything I said as absolute truth... my memory is a bit
fuzzy... I do distinctly remember the computer being fried by that program,
though. And no, I was not the one who did that... I was only a spectator)
On another note, some of the earlier Commodore PET's had a register in
their video controller that set the number of scan lines (or something like
that). On some of them, you could tweak this register to get a better looking
screen display. On others, doing so would toast the video circuitry. While
this is not strictly in the "exploding computer" category, in the PETs the
monitor WAS in the same case, so it has the same effect on the poor guy who
watches it happen :-)
----------------------
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Message-ID: <18989@ucbvax.BERKELEY.EDU>
Date: Thu, 21-May-87 13:53:35 EDT
Organization: School of Education, UC-Berkeley
A few years back, PC magazine and PC World published claims that it was
possible to program the video controller chip in the CGA
(Computer Graphice Adapter) video adapter board
so that an ordinary color monitor's flyback transformer would overheat
and catch fire. Has anybody done this? Is it included in anyone's copy
detection? Anyone's error handler?
It should be real simple to do. That chip gives you pretty good control
over the video waveform, so you ought to be able to play with the timing
of the horizontal sync pulse, (which, as I remember, was the way the trick
was done.) has anybody extened these techniques to the more sophisticated
EGA (Extended Graphics), and PGA (Professional Graphics).
[End of collection forwarded to Risks by Mark Brader--msb]
------------------------------
End of RISKS-FORUM Digest
************************
-------