The RISKS Digest
Volume 15 Issue 18

Wednesday, 27th October 1993

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…


o Saab Story: Cars rolling off the assembly line
Vernon L. Chi
o Yet another date overflow bug
David Lamb
o OZDISK - Big Brother Down Under?
Mike Bell
o Russian Hacker Activity
David Fowler
o Thank you
Lauren Wiener
o Re: CERT and "security incident" handling
Doug Moran
A. Padgett Peterson
Scott Schwartz
Bruce R. Lewis
Nick Rothwell
o Re: The FAA discovers HERF
Dennis Chamberlin
o Info on RISKS (comp.risks)

Saab Story: Cars rolling off the assembly line

Vernon L. Chi <>
Mon, 25 Oct 93 07:39:07 -0400
>From Road & Track, November 1993:

  In Sweden, an empty automated Saab factory jump-started itself and assembled
  24 cars and rolled them off the assembly line into the factory wall.  A
  worker finally discovered the mishap and found an impressive pile of chrome
  and steel.  A Saab official noted the damage was minimal.  `Our assembly
  lines run slowly, and we have big bumpers,' he said."  I like it.  The
  robustness here was mechanical, and obviously was able to accommodate an
  unintended run of at least 24 cars without major damage...

       [Before most of you were born, a radio comedian named Henry Morgan
       once had a shtick commercial for a fictitious car manufacturer:

           BUSKIRKS are now rolling off the assembly line.
           We will start delivering them as soon as we can
           get them BACK ON THE ASSEMBLY LINE.

       Ergo, the SUBJECT line, with PGN is delving back into his youth.]

Yet another date overflow bug

David Lamb <>
Wed, 27 Oct 1993 13:44:37 GMT
This appeared in comp.os.linux.announce today.  It's surely "old hat" to risks
readers, who probably remember tales of more egregious date overflows in
banking systems in 1969/70 and 1975/6.  I suppose that in a "free" operating
system like linux, one gets what one pays for — but I'm a bit discouraged
that such simple conventional wisdom as is needed to avoid this escapes most
of our practicing programmers.

    If you don't use term, read no futher. If you don't know what term is,
    read no further.

    [term is a package which allows you to open multiple sessions over a single
    modem dialup connection; like a rudimentary SLIP. --mdw]

    Well, it had to happen. Sometime on Oct 26th, term died, probably all
    around the world. The problem is that a variable was defined to be
    'int' instead of 'unsigned int', and so, as a result, it overflowed.
    This caused all the packets to stop being sent. Fun, huh?

Software Technology Laboratory, Computing and Information Science
Queen's University, Kingston, Ontario, Canada K7L 3N6   (613) 545-6067

OZDISK - Big Brother Down Under?

Mike Bell <>
Fri, 22 Oct 93 10:04 EDT
This week TV Ontario re-broadcast an Australian documentary "GUMSHOE" which
depicted - in fly-on-the-wall format - the work of Australian private

One of the detectives explained that the greatest changes in recent years have
been the mobile phone, and "OZDISK" - a CD-ROM which he then demonstrated.

It allows the user to search and cross-reference by telephone number,
street address, and name. It was implied that all the names of people
living at an address were indexed.

Among the uses demonstrated: it allows the investigator to identify people
living at an address from a phone number; to pretend to be a friend of the
neighbours to gain a persons's confidence; to explain a presence in an area.

Presumably it allows con-men, burglars and kidnappers to do the same.

Is this a restricted publication, or can anyone get one? And what
organisation is "responsible" for publishing it?

Mike Bell, Leapfrog Software Technology Inc.  <>
Tel: +1 905 857 4326  Snail: 172 Ridge Rd, Bolton, Ontario L7E 4V4 Canada

Russian Hacker Activity

David Fowler <>
Sat, 23 Oct 93 23:35:30 PDT
   According to the Associated Press last week, computer hackers nearly
succeeded in stealing 68 billion rubles, or about $57 million, from
Russia's Central Bank in August.

   The unidentified hackers got into the bank's computer using a random
combination of access codes, then tried to transfer the money into accounts
at commercial banks. The attempt failed because the thieves lost too much
time transferring the vast sums, and the bank detected the computer leak.

    Since the beginning of the year, according to the AP, the Russian
Central Bank has discovered attempted thefts and fraud totaling about 300
billion rubles, or $250 million.

   This was only the latest in a string of thefts and attempted frauds at
the state-run bank since the breakup of the Soviet Union, bank officials
said.  Bank officials told AP that, last year, thieves stole billions of
rubles from the bank using false "avisos," or documents transferring money
from one bank to another.

Thank you

Lauren Wiener <>
Sat, 23 Oct 93 12:07:34 -0700
_Digital Woes: Why We Should Not Depend on Software_ has been published by
Addison-Wesley, and I just wanted to thank everyone who has been posting to
comp.risks since 1990.  Listening in on this discussion has been a real
education for me, and I don't think I could have gotten such an education
anywhere else.  Thanks to all of you for the honesty, the insight, the
frankness, and the intelligence.

   — Lauren Ruth Wiener

"security incident" handling — comments on CERT's policy

Doug Moran <>
Wed, 27 Oct 93 12:28:03 PDT
The subject of what and how information about computer security problems
should and should not be made available has been discussed here and in a
variety of other forums.  Typically these discussions are in abstract
terms, and focusing on the difficulties of balancing competing problems.
I have been encouraged to submit the below description of my interactions
with CERT (Computer Emergency Response Team) because people who don't
deal directly with CERT have been surprised at the extreme position that
CERT takes on these matters: it is not much of an exaggeration to say
that CERT's position is that they are an input-only channel.  Since
CERT is being used as a model for similar groups, their approach takes
on even wider significance.

My background: I handle part of the management of a cluster of approx
50 Suns.  Because my group collaborates with various companies and
universities, I wind up getting involved in dealing with breakins at
some of those other sites ("collective insecurity" :-) ).
My site is well-known (we were one of the first sites on the original
ARPAnet), and  I am known to people at CERT — I should have no problem
getting vetted as trustworthy if CERT were to do that.  The following are
my personal opinions (not my employers) based on my experiences plus those
of the system managers and administrators that I interact with.

Previous Incidents


Over the years, I have dealt with a variety of breakins and attempts.
When it was possible to trace the cracker forward or backward, I would
send the M.O. (modus operandi = profile) of the cracker (not just the
holes that he tried to exploit, but also a list of symptoms that a site
should look for).  After the creation of CERT, I would also send this
MO to them.

I now regard the minuscule effort needed to send CERT a copy of this
MO a waste of time because CERT refuses to provide this information
to sites that have been broken into.  I have personal experience with
this on both sides:
1. I have contacted CERT about a particular cracker and given a
   substantial profile and asked if CERT could tell me anything more
   about this particular cracker.   All CERT has been willing to provide
   is their generic documents.  In backtracking the cracker, I found
   a site that had identified the cracker's MO and reported it to CERT.
2. Similarly, I have been the one to report an MO and later be contacted
   by a site that had gotten nothing from CERT, but had learned of me
   by backtracking the cracker to a site that I had contacted.

Current Incident

A site with which mine has substantial interactions was broken into by
a cracker in mid-September, and consequently I got involved in helping
with the problem.  We very quickly found several of his tools and enough
other things to constitute a reasonable signature.  We contacted CERT
and they claimed to have no knowledge of this particular cracker.

The cracker was using captured passwords to daisy-chain from site to
site.  Unfortunately, we didn't immediately find all the holes and
backdoors that he had planted.  Consequently, the cracker persisted
in having access to that site for some time, thereby having a chance to
capture additional passwords.  In the followup, we found multiple other
sites that had been broken into by the same cracker (coming or going).
None of these had gotten any useful information from CERT.

Two days before the recent CERT announcement that there was a hole in
sendmail, I got a message from the admins for that site: "he's back".
They found a backdoor that he had installed, but were unable to figure
out how he had gotten in to install it.  Suddenly, with the announcement
of the hole, several things we had seen (and reported) seemed to fall
into place.

Because this cracker had earlier probed my site from various other places
on the net (we had already closed the holes he was exploiting), I was
concerned that he might have used this newly found hole to compromise my
site (remember, he had broken into a number of the universities and
companies with which we collaborate).  I called CERT and asked if they
could tell me what symptoms to look for to determine whether or not this
hole had been used.  I was told that there were definite symptoms, but
that CERT couldn't tell what they were because that would give away what
the hole was.  I reminded them that their advisory said
    "** This vulnerability is being actively exploited and we strongly
    recommend that sites take immediate and corrective action. **"
and that we had already reported a breakin-in-progress (at the site I was
helping), but to no avail.  I subsequently got the information I needed
from another source, but only at the cost of not being able to pass it on.

One of the many other sites that had been broken into by this same cracker
posted to various relevant newsgroups a list of the sites that it had
determined to have been compromised (the list was several screens long).
CERT posted the following response to those newsgroups:
 > Newsgroups:,comp.sys.sun.admin,,
 > From: (CERT Coordination Center)
 > Subject: Re: Security Incident — many sites exposed.
 > Reply-To:
 > Organization: CERT Coordination Center
 > Date: Tue, 19 Oct 1993 15:51:54 EDT
 > CERT is aware of the incident reported earlier today and we are
 > working to help resolve it. It is CERT policy not to publicly
 > disclose sensitive incident information, particularly names
 > of sites that are, or may have been, involved. Therefore, we will not
 > post the list of affected sites here or on any other netnews group.
 > We are reviewing the information concerning this incident and we will
 > endeavor to contact all sites known to be affected within the next
 > 24 hours.  We would appreciate your patience and ask that you not
 > contact us about the earlier posting, via either e-mail or telephone,
 > so that we can concentrate our resources on contacting and helping the
 > affected sites.
 > CERT Coordination Center

>From what I can determine, what CERT means by "help" is that they tell
the site that they have been broken into and then provide the generic
documents on security patches and practices.  The sites I have talked
to never have gotten information specific to a particular incident.
Note also that this "response" comes more than a month after the first
reports to CERT of this cracker (or a very similar one).


Caveat: since CERT is almost exclusively an input-only channel, it is
hard to determine what they knew and when they knew it.

While I agree with the sentiment in CERT's posting above (that it is
undesirable to publicly identify sites that have been broken into), I
cannot disagree with the action of the site that posted the list of
compromised sites — the cracker seemed to be spreading faster than he
was being found and excluded.  (Note that I am not identifying the site
that I went to help, nor am I free to publicly discuss details).

In my opinion, CERT's policy contributed substantially to the number of
sites broken into and the persistence of this cracker on the network.
First, when a system administrator contacts CERT and is told that CERT
doesn't recognize the pattern of a given breakin, the SysAdmin is likely
to believe that he is dealing with an isolated case, either involving a
local user or just one or two other sites.  The MO of this cracker left
little evidence to contradict this view.  Consequently, a SysAdmin could
easily focus on the wrong containment measures, allowing the cracker to
continue to use his site as a base to attack other sites.

Second, because CERT is unwilling to release info on the various tricks
and tools that the cracker was using, a SysAdmin could easily stop short
in his cleanup, after finding only some of the holes the cracker was using
or had installed.  This is what happened at the site I was helping.
This gave the cracker time to capture passwords needed to daisy-chain to
other sites.  Similarly, since CERT refuses to give any advice on what
holes the cracker might be using, the SysAdmin may well spend his time and
efforts closing holes that aren't currently being exploited, giving the
cracker time to further compromise that site and others.

CERT would seem to be a classic RISKy system — because it doesn't behave
the way people think it does/should, it causes people to take the wrong
actions, especially during crises.  And the classic way to deal with such
a system is to teach people to ignore it.

-- Douglas B. Moran

CERT Reports and system breakins (PGN in RISKS-15.17)

A. Padgett Peterson <>
Fri, 22 Oct 93 08:44:44 -0400
>... but this one
>seemed particularly relevant to the bigger picture, which is that system and
>network security stinks in most systems, particularly those on the Internet.

I tend to agree. System security which is based on a username/password
evidences a single point failure, partially caused by the Internet mail
scheme which, unless certain simple steps are taken, passes a fully
formed account username/address in the mail header.

Over the last several months, I have been examining the situation and have
come to the conclusion that there is a relatively simple means to add
another layer of security that, for some reason, no one seems to use.

Back in antediluvian times, we had mainframes with terminals connected
directly to ports. By which port was accessed, we knew exactly where the
user was. Then cam networks and "virtual terminals". Suddenly we no longer
knew where the terminal was that the access request was coming from.

With Ethernet however, every packet contains two basic addresses (TCP/IP adds
two more IP addresses but that is a software fiction). These six-byte hardware
addresses are burned into firmware and every card has a unique address.
Originally administered by Xerox, this address consists of a three byte
manufacturer's field followed by a three byte serial number. It would be very
difficult (well, nothing is impossible but this would be close) for software
to forge an address using commercial equipment and collisions should be

Given this number and a database to correlate the ethernet address to a
particular system/location, it is possible to identify not only the user
with conventional means, but also determine whether the access is from a
known terminal. Further, since manufacturer IDs are unique also, if the
address starts with 00:00:C0, one can tell that the terminal is PC based
since those cards (Western Digital now SMC) are only used in PCs.

If then, the IP address in use was assigned to a SUN workstation, the
system can then determine that something funny is going on.

More common applications would be for designation of "secure" and "insecure"
terminals, refusal of certain information classes to PCs, automatic
software updates by system number. The list goes on.

The unfortunate situation is that it was like pulling teeth to find first
a good listing of addresses/owners (Michael A. Patton's listing from MIT
- available from FTP.LCS.MIT.EDU with the name pub/map/EtherNet-codes - is
the best I found), and secondly how to extract that information in a
reasonable manner (Ralf Brown's "Interrupt List" will have some new entries
in the next issue), but it can be done - and not just by a sniffer.

As a Proof of Principle, I put together a small .COM file that can be used
as part of the login script for a Novell server to retrieve the hardware
address of a PC client (well, I have PCs at home so...). This can be exported
into a database lookup of known systems to identify exactly which system the
client is logging in from. The synergy available from having this information
should be obvious.

The program is ETHCRD and is FreeWare. It will return the following

  1) Six-byte hardware address of the client's Ethernet card
  2) Whether a packet (TCP/IP) or Novell (IPX/IPXODI) driver is in use
  3) The card manufacturer's name

The important news is that It Can Be Done.


Re: CERT Advisory - SunOS and Solaris vulnerabilities

Scott Schwartz <>
Fri, 22 Oct 1993 00:21:09 -0400
I'm surprised to see the /dev/audio thing: It's been discussed on the
net for years now.  Since the fbtab mechanism is so simple, it's odd
that SunOS doesn't ship with it taken care of, and amazing that Solaris
has apparently dropped (!!) the mechanism altogether.

Two obvious risks: Sometimes an OS upgrade is actually a downgrade.
Lots of other vendors probably have the same vulnerability, but no CERT
advisory to nudge them to do something about it.

Re: CERT Advisory - SunOS and Solaris vulnerabilities

Fri, 22 Oct 93 10:25:14 -0400
>Any user with access to the system can eavesdrop on conversations
>held in the vicinity of the microphone.

Maybe this has been noted in RISKS before, but ISDN speakerphones are
said to have a similar vulnerability.

Bruce R. Lewis          Analyst Programmer
MIT Information Systems     Distributed Computing & Network Services

Re: CERT Advisory - SunOS and Solaris vulnerabilities

Nick Rothwell <>
Mon, 25 Oct 1993 18:17:08 +0000
>        1.  Obtain and install the appropriate patch following the
>            instructions included with the patch.

Hmm. If I wanted to hack into a large number of SunOS machines throughout
the US, perhaps all I'd have to do is set myself up an FTP site with a
reasonably official looking name (I can purchase such through a local
Internet provider), disassemble and alter my copy of sendmail, and then
forge some mail from CERT to various security newsgroups, saying "there is
a problem with all your mail systems, we aren't going to tell you what it
is, but install this binary patch anyway because we say so."

My point being that this official-looking CERT Advisory message is
implicitly preaching security through obscurity. If someone will tell me
what this sendmail vulnerability is, then I can test for it, install a
patch, and see if it's fixed (which would give me some confidence that the
patch isn't a trojan, since it addresses a discovered weakness). Without
such information, I'm not going to do anything to sendmail on my SPARC just
because some SWAT team says so.

                        Nick Rothwell   |
     CASSIEL Contemporary Music/Dance   |

Re: The FAA discovers HERF (RISKS-15.14)

Dennis Chamberlin <>
Thu, 21 Oct 93 17:14:28 PDT
Winn Schwartau's article "The FAA and HERF" could be summarized: "There may be
a problem. We don't know anything about it, therefore we'd better act now."

He introduces a fragment of relevant theory that, though truthful, is
only sufficient to cause confusion about electromagnetic interference.

   "A fundamental axiom of electronics...An electric current creates a
   magnetic field, which travels at the speed of light in all directions.
   This is the principle of radio and TV and cell phones.
   If you stick a wire in the air, and connect it a completed circuit, a
   magnetic field will induce a current flow."
(more Dr. Science stuff deleted)

True enough, but the resulting induced signals are easily cancelled,
shorted, or swamped out by common engineering practices that have been
developed for the very reasons that, for example:

   "We live in an electromagnetic sewer, and God knows we shouldn't be playing
   'let's not worry about it' with computers flying planes at 37,000 feet."

For example, a coax cable within a magnetic signal field will have about the
same signal induced in both in the center conductor and in the shield.
Therefore, the interfering signal is almost perfectly cancelled out at the
destination. This is one important function of cables. (The article makes no
mention of this critical difference between wires and cables.) Other, more
powerful techniques are often combined with careful attention to transmission

"Antenna" is not a word that applies to cables. Antennas are not meant to
amplify signals but to radiate them. In fact, real antennas are often fed
by cables in order to prevent any radiation from taking place other than
from the antenna itself. I have never seen a mouse on any computer
connected with a wire or antenna.

I got a real laugh out of the description of the mouse and "wire" acting as
antenna, and the concern about the shield not ever actually reaching True
Earth/Power Company ground. Hm. Seems like the aircraft itself might also have
a serious problem here. Perhaps it establishes ground through some sort of
satellite link? :) (If anyone cares about the answer to this, please e-mail

The techniques for controlling interference have been advanced right along
with the rest of electronic engineering. Had solutions not been developed,
interference would have long ago put a stop to further advances in speed,
power, sensitivity, and complexity. But now we have everyday examples like car
radios (very sensitive receivers) delivering pure and faithful audio within
the same vehicle that is powered with an ignition system that delivers
wideband 40 000 volt discharges to the plugs. Or, MRI medical imaging systems
that utilize probably the strongest magnetic fields in common use, yet are
controlled by computers using electronics similar to those in laptop machines.

And, the airplane itself is a mixed and intradependent package of fairly
high-power emitters (radio, transponder, radar), together with computers,
cables, and sensitive receivers. Airplanes may be susceptible if they are not
properly designed, constructed and tested. But no convincing case for
susceptibility has been made. (The quoted Newsweek article does not establish

The statement "from a source close to the FAA" about installation of shielded
glass suggests a conspiracy to keep it quiet. It further suggests that money
is being spent to protect the FAA employees and their work environment, while
ignoring the associated "risk" to airliners and passengers.

His sinister implication completes the stereotype of cheap, fast, cute,
word-processed, scare journalism. It would have required only a trivial
investigative effort to reveal the unexciting fact that the FAA is aware of
the question, but they have not been able to demonstrate or reproduce the
symptom. Mr. Schwartau concludes that this is due to deficiencies in the FAA,
the equipment, or the investigators themselves.

But the designers of aircraft have anticipated that ground and airborne radar
would be a routine part of the operating environment, and took care of that in
design and test. FAA towers are not required to fly, and their design
constraints are not the same as those of aircraft. Nor do they go through
certification testing.

Perhaps the problem is so small, it is not easily seen through the grass.  The
reason the engineers are having trouble "trying to figure out what's
happening" may be that any effect is so slight or rare, there is nothing to
observe or measure. And, electromagnetic emission and interference is not
exactly a new or faintly-understood science.

The scenarios of RF-terrorists are silly. A terrorist that was both crazy
enough and clever enough to build a jammer would almost inevitably be
frustrated as his target aircraft just flew off and ignored him.

At any rate, Schwartau's recommendation is to take drastic restrictive action
based on non-knowledge. This is insufficient reason for the FAA to take
"stronger protective measures" against passenger electronics.

One reason is that more serious things happen nearly every day in commercial
air transport, but they generally don't fit into the fear-of-things-that-
can't-be-seen category, so we don't hear of them.  Instrument failures,
autopilot disconnects, software errors, navigation failures and human error
are among the many things that happen with more or less regularity in the huge
fleet. Even very adverse failures, such as runaway trim, are part of every
crewmembers' recurrent training, but are rarer because they get special
attention in design.

A second reason is that way up in the front of the craft is the truly critical
but redundant system called the flight crew. A very large proportion of their
past and continuing training is directed not at knowing how to fly, but in
knowing how (and being able) to fly when lots of things are broken. And almost
as important, at recognizing that they *are* broken. So rare, speculative, and
non-repeatable cases of of interference are generally not going to cause the
crew to freeze and gape wide-eyed as their multiple computers drive them
helplessly into the earth.

Air travel and airports are enough of an ordeal already, without further
stifling passengers with restrictions that deal with such ghostly "risks".
Nonetheless, the FAA has done this when there is a question of catastrophic
failure, e.g. loss of control. But Schwartau sees no difference between
low-level electrical interference and the integrity of the wing-attach bolts.

And, given the rare and non-repeatable nature of the symptom:

If such a blanket prohibition were effective, how would anyone know?

Please report problems with the web pages to the maintainer