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 7 Issue 01

Wednesday 1 June 1988

Contents

o RISKS of Evolution and Evolution of RISKS
PGN
o Re: Risks of automatic test acknowledgement
Paul Traina
o Computing Down Under
Willis H. Ware
o Computer Tampering Case to go to Trial
Joe Morris
o Software can destroy hardware
Willis Johnson and John B. Nagle via danno
o Cash on the Nail, by Daedalus
Brian Randell
Jacob Oestergaard Baekke
o Re: Down in the Dumps
Stan R.Z.
Mark W. Eichin
Dan Klein
Dan Franklin
o Info on RISKS (comp.risks)

RISKS of Evolution and Evolution of RISKS

Peter G. Neumann <NEUMANN@csl.sri.com>
Wed 1 June 88 16:45:00 PDT
Welcome to Volume 7!  There have been 472 RISKS issues in the past 35 months.
However, the number of contributions has been expanding dramatically of late
as RISKS goes further out into the internet.  (I note the big increase in
messages from Australia!)  (Countering that somewhat is the appearance of
specialized groups, such as VIRUS-L.)  To prevent RISKS readers from being
totally inundated with the deluge, the proportion of messages emerging from
my pipeline has been dwindling somewhat of late -- as I sharpen my
interpretation of the above guidelines.  (Apologies to those of you who did
not get any response at all -- if you feel that your contribution was of
PARTICULARLY BURNING INTEREST and that I might have missed it or not gotten
it, please resubmit with a note -- or think about refining it.)  By the way,
RISKS production will have to slow down a little during June, because of my
schedule; so, be patient.  Maybe with school recesses, discussion will slow
down also.  But the world never rests, and we can assume that there will be
a few stellar cases of interest to RISKS.  PGN


Re: Risks of automatic test acknowledgement (RISKS-6.93)

Paul Traina <comdesign!pst@unix.SRI.COM>
Tue, 31 May 88 11:56:55 PDT
As one of the culprits who found this feature in Erik Fair's *.test
message bouncer program,  I'd like to mention a couple of ways to protect
yourself (by the way, yes, it was an accident).

What is a *.test message bouncer?  If a user posts a message to "misc.test"
or "alt.test" this bouncer program will mail the posted message back to the
user.  This is often used by sites to determine if their news feeds are
making it out to the backbone (or, as in our case, to gather statistics
to determine the best news propigation path).

The symptom is that this one particular (the most popular) message bouncer
will send mail to every address on every From: line in the message.  This
includes From: lines in the message body.  Now that this feature has been
widely publicised in the "news.admin" newsgroup,  the best step is to warn
everyone before some net-terrorist decides to cause real havoc.

The message that caused the recent problems on the net had two features which,
when combined, resulted in a mess.
    (1) the message had 109 From: lines in the body
    (2) it was a large ~62k message

What happened?  Every site that had the message bouncer installed sent
out 109 62k mail messages.  Also, many of these mail messages failed because
of a bad address.  This lead to them to be bounced back to the originating
site (the one with the bouncer) to end up in the inbox of the Postmaster.
Needless to say, many sites had their spool partitions and usr partitions
filled to capacity within minutes of receiving that message.  Also, there
was a significant jump in uucp and Internet traffic (painfully expensive
to long distance uucp sites).

How can you protect yourself?  If you're not running Erik's program, you
are likely to be safe (check anyway to see if it has these same "features").
Modify your message bouncer to:
    (a) Send a reply to one "Reply-To:" or "From:" address (the
        first From: address in the header seems logical to me).
    (b) Don't send the entire message back, just the original header
        and a note saying "we got your message".

Paul            pst!comdesign@pyramid.com       ...!pyramid!comdesign!pst


Computing Down Under (Re: RISKS-6.94)

<willis@rand-unix.ARPA>
Tue, 31 May 88 17:37:55 PDT
I just returned from attending the IFIP/SEC-88 conference on the Gold
Coast of Australia.  It's a meeting that addresses protection of
information systems in the broadest context.  SEC-88 is the 5th in a
series of roughly annual meetings, and is sponsored by TC-11, a technical
committee of IFIP -- approximately the international analog of AFIPS.

In addition to doing a keynote talk on "Perspectives on Trusted Systems", one
of the fun things for me was to participate in an evening public forum on
social aspects of computer technology.  In addition to myself, there were on
the platform an Australian computer expert (who organized the conference) and
two Australian politicians -- one a regional official of the Labor Party and
the other, a present conservative Member of Parliament.

I had been cautioned that the subject would almost certainly center around
the Australian ID card exclusively, and it did.  By the by, the story that
was told to me, and verified by something that I read down there, was that
the only reason that the legislation did not go into effect earlier was
that it contained a technical flaw; namely, in the haste of getting it
ready, a switch-on date was inadvertently omitted from the law.  This fact
came from a prominent member of the Australian Computer Society.

The argument that developed during the evening -- and it apparently is the
nub of the Labor Party position -- is that Australia has too much tax
fraud [sic] and that the ID card is the answer.  It seemed to me that the
proper word was "tax evasion."

It seems that the Laborites feel that too much income is escaping the tax
authority, and that it should be collected to make more revenue available
for social and other programs.  Obviously what Australia wants to do is
corral the taxpayer, as the IRS does with its Taxpayer ID; Australia wants
to be able to do the analog of tracking supplementary money flows as
reported on the various form 1099s and similar documents here.

Other than the tax-related matter, no other argument was given for the
institution of a universal ID card and number.

There was an amusing comment from the floor.  A member of the Swedish
delegation pointed out that Sweden has had a population register for
decades, if not centuries, and Sweden has substantial tax fraud still.

My concluding comment was to point out to the Labor person that it seemed
to me that he had a solution in search of a problem.  In the best
system-analysis tradition, I observed that the tax problem could very well
be real, but that it looked as though it had been assumed that a universal
ID was *THE* answer.  There clearly are other answers and the government
ought to do a more careful analysis of alternatives.  Something in the
spirit of the US/IRS arrangement would meet their tax needs, without
subjecting the Australian population to all the RISKS associated with a
genuine universal personal ID.

The whole thing was covered by a TV crew whose interviewer chaired the
session.  I was told that a lot of air coverage was given to the occasion
the following night, but I did not see it.

There seem to other RISKS in the Southern Hemisphere also; there has to be
one somewhere in the following story.  En route, I read an Auckland, NZ
newspaper which reported a cable car incident.  The Auckland cars are not
in the spirit of the San Francisco ones but evidently more like an
inclined railway running up and down a steep street in a more or less
straight line.

Seems as though a cable car had crashed into a bumper at the end of the line
with some injuries, but the RISK content is in the final words of the article:

     "The City Council had just spend [NZ]$90,000 
     reprogramming the onboard computer."

Willis H. Ware, RAND Corporation, Santa Monica, CA


Computer Tampering Case to go to Trial

jcmorris@mitre.arpa <Joe Morris>
Tue, 31 May 88 17:29:53 EDT
Organization: The MITRE Corp., Washington, D.C.

From the _Washington_Post_, 31 May 1988, page D-1 (without permission, of
course) comes the following article (credited to _Newsday_):

TEXAS TO HOLD A LANDMARK TRIAL ON COMPUTER TAMPERING BY 'VIRUS'

Texas prosecutors are preparing to go to trial in one of the first criminal
cases in the nation involving spohisticated tampering with a computer's
programming.

Donald Gene Burleson, a 39-year-year-old Fort Worth programmer, has pleaded
innocent to charges of computer sabotage and burglary involving the USPA
and IRA, Co., a Fort Worth-based insurance and securities concern.  He is
free on $3,000 bail pending a July 11 trial.

Burleson has lost a civil action in connection with the alleged 1985
computer tampering, and has been ordered to pay USPA about $12,000 in damages
and interest.

Prosecutors charge that after being fired in September 1985, Burleson deleted
records of thousands of sales commissions owed USPA employees from the
company's computer system, and also introduced into the system a hidden
program that would erase such data in the future.

Davis McCown, head of the Tarrant County district attorney's economic crimes
division, said in an interview last week that  the program "had the ability
to move through the [computer system], to change its name and to relocate."

[discussion of Trojan horses and viruses (virii?)]

[...] Burleson denied the charges and [said] that the company is blaming him
for someone else's actions.

"They really have no proof," [his lawyer] said.  "Anybody could have done
the deletions" from the commission payment records.


Software can destroy hardware [From comp.sys.ibm.pc]

<ncar!ico!ism780c!microsof!danno@rutgers.edu>
Tue May 31 17:50:47 1988
Date: 24 May 88 01:49:55 GMT
>From uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!violet.berkeley.edu!willis Mon May 23 18:49:55 1988
From: willis@violet.berkeley.edu (Willis Johnson)
Subject: How did this program burn out two monitors?
Organization: University of California, Berkeley

I recently compiled a program that is supposed to do graphics on a Hercules
graphics adapter.  I've used a similar routine before, and I would have
sworn there was nothing wrong with the software.  Maybe the files got
corrupted.  When I ran the .exe file, my monitor made a high-pitched whine,
then the power light went off, and a crackling noise came out of the back
until I pulled the power cord.  Curious about whether this was a
coincidence, I took the program to work and tried it on an extra monitor I
had there.  The second monitor burned out too! I thought it was impossible
to damage my monitor and adapter with software.  Does anybody have any ideas
what caused this?  I'll post the .exe file and source (in C) to any brave or
curious souls who request them.

The hardware:
    1st time:  homebrew PC clone with generic Hercules clone card
           Quimax DM-15 amber monitor.

    2nd time:  Leading Edge Model D, "turbo" with built in
           Hercules compatible adapter, Quimax DM-14
           amber monitor (an earlier version of the DM-15).

Neither video adapter was damaged.  Both monitors are DEAD.  

    Willis Johnson
    willis@violet.BERKELEY.EDU
    (415) 548 - 3023

>From uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!ucbvax!decwrl!labrea!glacier!jbn Mon May 23 22:29:15 1988
Path: microsoft!uw-beaver!cornell!rochester!bbn!uwmcsd1!ig!agate!ucbvax!decwrl!labrea!glacier!jbn
From: jbn@glacier.STANFORD.EDU (John B. Nagle)
Newsgroups: comp.sys.ibm.pc,comp.arch,comp.graphics
Subject: Re: How did this program burn out two monitors?
Date: 24 May 88 05:29:15 GMT
Reply-To: jbn@glacier.UUCP (John B. Nagle)
Organization: Stanford University

       This is an old known bug.  You can burn out the IBM monochrome
monitor by stopping the horizontal sweep while keeping everything else
running, and the Hercules card gives you enough control to do this under
software control.  The video chip lets you select the horizontal and
vertical sweep rates independently, and zero rates are possible.  However,
the horizontal sweep is used as the oscillator for a switching power supply,
as is typical in TV circuits, and with the sweep rate at 0, DC flows through
a coil with high inductance but low resistance, producing an excessive
current that burns out the coil.

       Part of the problem is that the IBM monochrome monitor is a design
lifted from an earlier, pre-PC product line, the IBM Displaywriter, and in
that product, there was no potential vulnerability of this type.


Cash on the Nail, by Daedalus

Brian Randell <Brian_Randell%newcastle.ac.uk@NSS.Cs.Ucl.AC.UK>
Wed, 1 Jun 88 00:31:42 +0100
My original message to RISKS, with the copy of the Daedalus article, contained
(or more exactly, since my files do not indicate one way or the other, I
believe contained) an explanatory introduction about Daedalus, and his splendid
articles. It was not my intention to test the gullibility of the RISKS
readership!

Adding to the information that has since appeared about Daedalus:

  (i) he is, I'm pleased to say, based here in Newcastle,

  (ii) he has been claimed to be the world's most successful builder of
perpetual motion machines! (A fascinating example, whose actual method of
operation is still a matter of some mystery, is I understand in the
Ontario Science Center, and

  (iii) he was the subject of a splendid documentary on BBC TV recently,
possibly in the Horizon series, which is worth looking out for, not least
for its account of his perpetual motion machines.

Brian Randell


Re: Daedelus (RISKS-6.90)

Jacob Oestergaard Baekke <mcvax!iesd!jacob@uunet.UU.NET>
Tue, 31 May 88 14:08:10 +0200
  > For  years  now,  we  have been told that the cashless society is
  > just around the corner...

If this is the true condition of the cashless society in UK, you are
behind the Danish banks. For the last one and a half year I have been
able to do shopping and pay with my DanKort (in english: DanCard)
which is the card you receive from your bank if you want to have a
cashcard. In the Danish system all the banks has join forces and
developed a system with a card with crypt 4 digit PIN code on a
magnetic stip, a independent company runs the ATM automats, the pay
terminals in the shops etc. The system operated on high security
level; you get three attempts to enter your PIN code correct. If you
has not enter a valid code the card is automatical blocked and you
have to go to your bank, to raise the blockade. The obvious RISK in
this system is if anybody place a fraud ATM which just read the
content on the magnetic stip and the PIN code the custom taps in on
the keyboard. But at present I have not hear anybody trying this.

              Jacob Baekke, user of a DanKort.


Re: Down in the Dumps (dvk)

<srz@ATHENA.MIT.EDU>
Tue, 31 May 88 20:34:49 EDT
The Unix dump discussion illustrates having to balance two risks -- the risk of
committing errors as an all-powerful superuser, vs. the risk of having an
insecure system if access is improperly set for non-superusers.  As pointed out
by Brian Reid many months ago, giving system maintainers or administrators
special privileges, such as write permission on system directories, has its own
risks.  Unix is a complex system, and setting certain protections has
non-obvious side-effects.

For example, dvk advises that disks should be protected r--r--r--; in other
words, everyone will have read access to the raw disks.  This is equivalent to
giving EVERYBODY read access to ALL files on that disk! In some environments,
this may be ok, but other environments may want users to have some privacy.

Every site has to adopt some philosophy for dealing with Unix's all-or-nothing
approach to privileges.  I usually perform most system tasks as superuser, and
after a long (and sometimes painful) learning process, I'm now careful enough
not to destroy anything.
                                             -stan


Down in the Dumps (a true story)

Mark W. Eichin <eichin@ATHENA.MIT.EDU>
Tue, 31 May 88 18:53:30 EDT
   Dumps should be run as "sys", or some other non-priv userID.  Disks should
   be owned by "sys", and protected r--r--r--.  

Actually, r-------- is more appropriate... otherwise anyone who can
get to /dev (which should be *anyone* since /dev/null is in there) can
read the entire mounted disk, violating any security the filesystem
was meant to offer. Running a debugger with macros for opening up the
file system structure makes it easy to find files by hand...

Mark Eichin     SIPB Member & Project Athena ``Watchmaker'' 


Down in the Dumps (a true story) -- OOPS!

<dvk@SEI.CMU.EDU>
Wed, 1 Jun 88 11:38:00 EDT
Oopsie, oopsie!  I meant to say "protect you disks r--r------", but my finger
stuck and it came out "r--r--r--".  If you do the latter, then anyone can
read you disks, which is not such a great idea.                    -Dan Klein


Re: Down in the Dumps (and not being root)

<dan@WILMA.BBN.COM>
Wed, 01 Jun 88 12:19:52 -0400
This message gives some very sound advice; one can, and should, avoid root
privileges if at all possible with UNIX.  [... comment on  r--r--r-- ...]

There are also problems with doing system administration as someone other than
root in a networked environment.  Lots of people have their own workstations
and can configure them any way they like, pretending to be any user who might
have interesting privileges, like "sys".  Sun's current version of NFS does not
perform any serious validation, so if you export a filesystem to my workstation
via NFS, I can read and write any file on it simply by setting up an account on
my workstation with the appropriate user-ID.  The only exception to this is
root: an NFS client is never granted root privileges by an NFS server.  So
there may be reasons why some things HAVE to be owned by root, even when it
would be better to avoid it, thanks to NFS.  (Sun OS 4.0 apparently fixes this
problem.)  In this specific case, I don't think device files can be accessed
under NFS (and you don't need to make the root filesystem exportable anyway),
but anyone trying this kind of thing should be aware of the general problem.

    Dan Franklin

Please report problems with the web pages to the maintainer

Top