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 6 Issue 81

Monday 9 May 1988


o Congress, computer breakdowns, and the SDI
Gary Chapman
o Risks in timestamps (postmarks)
Alan Wexelblat
o Risks in the phone system
o Risks of banking — audio tellers
Daniel P Faigin
Alan M. Marcum
o Military Aircraft Crashes in Germany
Michael Wagner
Michael Bednarek
o KAL 007
Steve Philipson
o Atari ST virus hiding place
Allan Pratt
o Viruses and write-protection
Fred Cohen
Bill Murray
o Info on RISKS (comp.risks)

Congress, computer breakdowns, and the SDI

Gary Chapman <>
Mon, 9 May 88 11:02:30 PDT
Last week while the House of Representatives was voting on a funding bill for
the Strategic Defense Initiative, the House vote-tallying computer broke down.
The computer reported a vote of 358 ayes and 237 nays on an amendment to kill
the SDI program offered by Reps. Ron Dellums and Barbara Boxer.  The House only
has 435 members.

The irony was not lost on the opponents of the SDI.  Nevertheless, the "manual"
count of voice votes revealed defeat of the amendment 299-118.  

-- Gary Chapman, Executive Director, CPSR

Risks in timestamps (postmarks)

Alan Wexelblat <wex%sw.MCC.COM@MCC.COM>
Mon, 9 May 88 09:48:50 CDT
PGN's note about the folks who used predated postmarks to cheat on the
Superbowl contest reminded me of the following:


Risks in the phone system

Mon, 9 May 88 14:34:15 CDT
A Mother's Day fire in an Illinois Bell switching center in Hinsdale has
pointed up several RISKS resulting from evolution in the telephone system.

According to an Illinois Bell spokesman, "the switch seems to be alright", but
the cables entering the office were severly damaged.  Not surprisingly, phones
in the area served by the office are completely out of service.  However, my
home phones, which are connected to a central office 5-6 miles from Hinsdale,
are virtually out of service.  I can call some local exchanges (those served by
my switch), but I have no long distance service, no access to 611 repair
service(!), no access to information, and no access to a human operator (dial
0).  What is especially annoying is that attempting to use any of these
services simply results in return to dial-tone, rather than a message
indicating that there is a (known) problem.  Estimated time to repair is
variously quoted as three days to two weeks.

It seems to me that several recent trends have exacerbated this problem:
Centralization of operator services (no operator at my central office, so calls
to operator are routed over trunks).  Ditto for 611 and 411.  But, how to
report phone service out of order when you can't get 611?  Similarly, I can't
call Ill. Bell, because all of their numbers are 1-800 ones, which evidentally
must also be routed through the damaged trunk.

I also find it a startling RISK that my central office, which serves several
exchanges, including Argonne National Laboratory, apparently has interoffice
trunks to only one other central office.  It would seem that for reasons of
traffic balancing, if not redundancy, trunks to more than one other central
office would be good practice.

Is anyone in the Bell system listening?  Care to comment?

[I speak only for myself, as you guessed.]

Risks of banking — audio tellers (Re: RISKS-6.80, Ritchey Ruff)

Daniel P Faigin <>
Mon, 9 May 88 09:13:07 PDT
Our credit union also has an audio response system. I use it periodically, and
tend to like it when I use it. There are a couple of additional comments I
would like to make on top of what Ritchey has said.

For SSN-phobes, our system is worse. Our credit union uses SSNs as account
numbers, and assigns you a random 4-digit PIN. I can see risks in this in
response to line monitoring and playback threats.

However, the playback risks can only result in bounced checks.  Note that
access is limited to only your account, so money can only be moved between your
accounts. If a check is requested, it is mailed ONLY to your address of record.
The only risk there is that someone may intercept the mail. That's a wetware
problem :-).

I did run into one problem with the system. According to federal law, transfers
via systems like this are treated as telephone transfers. This limits you to 3
per month. One month, I exceeded this limit — or at least I thought I did
because the computer said it could not do the transaction because I had
exceeded the number of transfers for the month. I didn't believe it when it
happened, so I tried it again. It failed again. When I went to the credit union
the next morning to see what had happened, it turned out that, even though I
had gotten the error message, the computer had done the transfers.

Lastly, our system allows you to chain entry by using the * key.  For example,
to transfer money from subaccount 22 to subaccount 66, I can either enter the
and wait through all of the prompts, or enter, as a single action,
I haven't yet had the courage to do everything at once. I typically use * to
get me to the confirmation prompt.

W: UNiSYS/Defense Systems/System Development Group (nee SDC)
   2400 Colorado Ave;Santa Monica CA 90406;213/829-7511x5162 (or 213/453-5162)
H: 8333 Columbus Avenue #17; Sepulveda CA 91343
Email: (uucp) faigin@sdcrdcf.UUCP (arpa) faigin@SM.UNISYS.COM

Risks of banking — audio tellers (Re: RISKS-6.80, Ritchey Ruff)

Alan M. Marcum <>
9 May 88 18:06:43 GMT
The credit union to which I belong also has a touch-tone telephone
banking service.  When I signed up for it, they asked me to specify my
"password" (four digits).  Better than defaulting to something from my
SSN (and our state doesn't even use them for drivers licenses).

This system allows you to transfer funds between sub-accounts within
your account (sub-accounts are, for example, savings, checking, and
loans).  There is no provision for transferring funds to anything
outside your account, nor a provision for requesting a check be issued.
Had these facilities been provided, I would not have enrolled in the
service, because of the risk involved.

Alan M. Marcum              Sun Microsystems, Technical Consulting
marcum@nescorna.Sun.COM         Mountain View, California

Military Aircraft Crashes in Germany (Henry Spencer)

Michael Wagner new! +49 228 8199645 <WAGNER%DBNGMD21.BITNET>
Mon, 09 May 88 12:21
In RISKS 6.79, Henry Spencer, after quoting my original article, says:
> nuclear-reactor containment buildings are deliberately designed to
> survive a direct hit from a crashing airliner (not as fast as a
> military jet, in general, but much, much heavier).

I didn't mention this in my original posting, but shortly after the crash near
the nuclear reactor, the interior minister got on the radio and told everyone
roughly the same thing.  I suppose this was meant to be reassuring, but it
doesn't seem to have succeeded.  All of these low-level flights are over
populated areas (there are no un- or sparsely- populated areas in this part of
Germany!), and the residents are scared.  There is now a debate going on as to
whether such low-level flights will be tolerated any more.

To try to put this in perspective, a plane crashed into a McDonalds in Munich
about a year ago, so planes falling out of the sky on people's heads is
currently a hot topic here.  An article in "Der Speigel" a while ago talked
about crowding in the air.  It made the air over O'Hare sound like a Sunday
stroll in the park.  Particularly interesting, in light of this discussion, was
the difference in air patterns that the militarily-proscribed airzones made.


Re: Military Aircraft Crashes in Germany (RISKS-6.79)

Michael Bednarek <munnari!!u3369429@uunet.UU.NET>
9 May 88 02:11:38 GMT
<> In all, 35 military aircraft have fallen out of the skies here since 1960. 

That number (35) is definitely wrong. I lived until 1983 in Germany, and by
that time more than 120 crashes were reported. Mostly Starfighters.

KAL007 - the deafening noise continues (RISKS-6.79)

Steve Philipson <>
Mon, 9 May 88 12:42:03 PDT
In RISKS-6.79 Clifford Johnson <> writes:

>                                         ....  I think that PGN's tentative
> suggestion that the matter might still be incompletely unravelled simply
> cannot be denied - at least until a public inquiry is instigated.

   Almost assuredly the matter is "incompletely unravelled [sic]", but 
it is also certain to remain that way, public inquiry or no.  Such 
investigations are notorious for their failure to find facts and 
establish definitive chains of events.  Take for example the Lindbergh 
kidnapping, Sacco and Vanzetti, J F Kennedy's assassination, or the 
current Contragate investigations.  Such public inquiries have often 
resulted in the wrong answers being "found", or no answers at all.  If 
answers do come out, they emerge many years later, after responsible 
parties are out of public office or deceased.  Even then, such revelations 
are questionable as verification remains difficult.  

   The discussion over the nature of the course deviation is, at best,
academic.  We cannot prevent deliberate course deviations.  However,
we have identified several possible ways for such a deviation to
occur unintentionally.  What we should and are concerning ourselves
with is how to prevent such errors in the future, and to establish
systems and procedures that will prevent loss of life and property 
should other errors occur.

Atari ST virus hiding place

Allan Pratt <ucbcad!ames!atari!apratt@ucbvax.Berkeley.EDU>
Mon, 9 May 88 10:14:26 pdt
A perfect hiding place for viruses on the Atari ST has come to my attention.
The reason it's interesting is it is a place where a VERY LARGE virus can
live — much larger than just the boot sector of a floppy.

The hole exists because the ST formats floppies with five-sector FATs
(File Allocation Tables) even though at most three sectors will be used. 
Since there are two FATs per disk, this leaves four sectors for the
virus.  A boot-sector virus could be five sectors in length without
impacting the user-visible free space on the disk. 

The sectors in question are logical sectors 4, 5, 9, and 10 (where the
boot sector is sector 0).  These sectors are always zeroed by the
built-in formatter (I can't speak for others).  The rationale, I
believe, for the five-sector FATs is so the root directory of the volume
will appear on Side 1 of a double-sided disk, so a single-sided drive
will not be fooled into thinking it can work with the disk. 

I asked PGN about posting this — about the tradeoff between warning the
friendlies and informing the hostiles about this hiding place.  As PGN
pointed out, "...  the underground will find out anyway.  The crackers
are networked better than everyone else."

So here is my posting.  The cure for an infected disk is to make the
boot sector non-bootable, and zero the four sectors listed above. 

Opinions expressed above do not necessarily — Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt

    [By the way, there is tons of stuff on VIRUS-L that is not appearing
    in RISKS.  For those of you with a burning interest in viruses, please
    join VIRUS-L, as indicated in RISKS-6.75.  PGN]

Viruses and write-protection [RISKS-6.79]

Date: Thu May  5 16:40:20 1988 CDT
From: Dennis Director <>
Subject: Viruses and write-protection                          CURIOUS.  PGN]

[From: Dennis Director <>]
>I have an XT-compatible computer with DOS 3.2 and all of its utilities and
>programs in the write-protected portion of the hard disk.  I invite both Dr.
>Fred Cohen of the University of Cincinnati and William Murray to come to my
>office ...                  I am (100%) sure that none of these programs will
>modify my boot block, my partition table, the operating system files or any of
>the DOS programs (.COM or .EXE) stored on my hard disk, which will be hardware

    What makes you think all viruses do only this?

>A scratch area of the hard disk will be writeable at all
>times.  Simply copying a Trojan Horse into the scratch section of the disk,
>should obviously not be considered "infecting my system".

    Copying a "Trojan Horse" onto your system would not constitute
    infecting it even if it were in your operating system. Since you
    don't seem to know what a virus, I would suggest that you
    purchase a copy of my dissertation for a more formal definition.
    (sending me $20 will buy it).

    I assume from your comment that it would however be considered
    "infecting your system" if we wrote a virus that infected source
    programs in your "scratch" area. If they then infected floppies
    and other information, this would also be infection, and if when
    you finally did write enable your hardware protected disk to put
    in another "protected" piece of software, the virus spread into
    that area, that would also be considered infecting your system.

>    Since Dr. Cohen has stated that "you cannot write protect
>lotus, etc because of copy protection" we will also have a copy of Lotus
>123 installed and working in the write-protected section, as we have had
>for almost two years.

    Lotus disks that I have seen at a number of sites have had this
    property, that is not to say that it is impossible to make them
    work that way. We contacted Lotus to have them make available
    a version with this property, and they refused. I did not say
    that for all lotus implementations, write protection was not
    possible, only that we (and you if you were in the set of people
    with the versions of lotus we were using) could not write
    protect them and have them work in the systems that we were
    working with. If lotus has backed off of this policy, I would
    only be happy to hear about it, but since your copy is so old,
    it may be that a recent change in their policy has made this
    impossible for newer versions.

> This will be a fully legitimate copy-protected
> installed version of 123.  It runs perfectly from the write-protected
> zone and cannot be infected.

    Neither Bill Murray nor I has ever said that you can modify
    information that is physically write protected, and I doubt
    if either of us ever would. What we said is that it is only safe
    if it is 100% protected 100% of the time. Since you have already
    admitted that it would be possible to infect the writable part
    of your hard disk, I assume that you in fact agree with us.

    On the other hand, you should agree that you do not know for
    certain if there is or is not an infected program on the write
    protected segment of your hard disk, and that when you install
    software on this part of your disk, it is entirely possible that
    without special precautions, you could infect one of those
    temporarily write enabled files. Furthermore, I am not convinced
    by your statement of belief that your disk is in fact write
    protected in hardware. I have seen many people who believed such
    things become unpleasantly surprised.

> Why go on debating that which can be simply demonstrated? Seems
> like a fair offer to me!

    In many cases, it cannot be demonstrated that it is impossible
    to do something simply by trying to do it. If you study the
    philosophy of science (see a famous work by Karl Popper), you
    will find that "FOR ALL" statemewnts covering infinite sets
    cannot be verified by finite numbers of supporting examples.
    They can however be refuted by a single example. If we succeeded
    in infecting your system, it would prove you wrong, but by
    failing to do so, it does not prove you right.

    Also, it is customary when proclaiming perfection (even with the
    various nebulous "except"s here and there) to make it worthwhile
    to demonstrate counter examples. I would suggest that in making
    such a challenge, you offer a $100,000 bet, so that if we decide
    to take you on, it will be worth our time to take you down, and
    so that if we take you on and fail to take you down, you will be
    able to have a very nice meal in your new home.

            Fred Cohen

D. Director: "Enough is enough."

Mon, 9 May 88 12:34 EDT
Dennis Director and I agree on the following:  enough is enough.

However, Director seems to believe that somewhere, both F. Cohen and I, have
asserted that write protection is not sufficient for protecting an operating
system from infection by a virus.  We have not.  Indeed, we have both conceded
that 100% protection of a hard disk 100% of the time results in 100% protection
of the hard disk from infection.  That I have so conceded is a matter of
record.  That I have ever asserted otherwise is not a matter of record.  If it
were, I am sure that Director would cite it.

Therefore, Director's challenge to me to prove that which I have never
asserted, can justly be construed as disingenuous.

What I have said, and will continue to say until I begin to get feedback that
the message is being heard, is that making one, or even many, machines immune
to infection is not sufficient to prevent the spread of the virus.

Director insists upon seeing the "protection of the operating system and other
commonly used programs" as the issue.  I do not blame him; if I were in the
business of selling write protection, I suspect that I would see it that way

Nonetheless, I will continue to assert that it is the SPREAD OF THE VIRUS,
rather than the protection of one or more systems, that is the issue.

I must confess to a great deal of disappointment that all of the response to my
review of Director's product has focused on assertions that I have been
extremely cautious not to make and has been totally silent on those that I have
gone to such great pains to make.  I feel much as George Washington must have
felt when writing to the Continental Congress: "Is anybody there?"

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114                          
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                

Please report problems with the web pages to the maintainer