The RISKS Digest
Volume 19 Issue 85

Tuesday, 14th July 1998

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…


Hong Kong Airport emulates Kuala Lumpur
Amsterdam airport down
Premature airbagulation
Jamming devices to cut noise pollution in Japan?
Keith Rhodes
Russia nearly launched nukes in '95
John P. Wilson
More satellite problems
Joan Brewer
Possessing fake IDs soon to be a federal crime
Declan McCullagh
Cisco backs backdoor for Internet wiretaps
Declan McCullagh
Y2K as a necessary event: Contingency plans needed
Bob Frankston
Re: Key management and Alan Davidson's message
Stephen Kent
Re: Vendors unite against bad applets
Li Gong
Re: Defining the line between hacking and web surfing
Michael Hogsett
Risks of trying to filter spam from newsgroups
Ben Klausner
REVIEW: "Maximum Security", Anonymous
Rob Slade
REVIEW: "Windows NT Security Guide", Stephen A. Sutton
Rob Slade
Info on RISKS (comp.risks)

Hong Kong Airport emulates Kuala Lumpur

RISKS List Owner <>
Wed, 8 Jul 98 12:56:58 PDT
(The emu was late?)  Tons of produce rotted.  *The New York Times* 8 Jul
1998 has a picture (but no story) of many baggage containers that could not
be sent from the newly opened Hong Kong airport, which had to be trucked
over to the old Kai Tak airport.  According to an item contributed by Daniel
Graifer, the problem was attributed to a "complete breakdown" of the inbound
cargo-handling system, including the loss of all cargo records.  There were
also lots of passenger delays and automated baggage-handling delays.  Of
course, everything reportedly had worked perfectly in the earlier tests.

Amsterdam airport down

sinteur <>
Mon, 13 Jul 1998 09:08:14 +0200
At about 13:00 on 11 Jul 1998, one of the busiest days in the year for
Schiphol, the Amsterdam Airport, a computer malfunction stopped just about
all air operations.  According to the Dutch newspapers, some malfunction in
the Triple A (AAA) system in air-traffic control blanked all screens,
forcing the airport to put all traffic 'on hold'. It took about 30 minutes
to get the system back up, and the rest of the day to clear the resulting
mess.  According to a spokesperson, "You can't use full capacity at once,
you have to build that up."

The Triple A system has been in use since 1 Jun 1998.  Some more interesting
quote that appeared in the newspaper: "Stories about ripped-apart cables are
nonsense.  The defect has been fixed, and we're not afraid it will happen
again."  [At least two risks in this quote: what do you tell your customers,
and what do you mean, you're not afraid it will happen again?]

Premature airbagulation

"Peter G. Neumann" <>
Tue, 14 Jul 98 8:32:53 PDT
After 130 reported injuries due to gratuitous deployment of automobile
airbags, General Motors and is recalling almost one million cars (1996 and
1997 Chevy Cavaliers and Pontiac Sunfires, and 1995 Cadillac DeVilles,
Concours, Sevilles, and Eldorados).  The Cavaliers and Sunfires have a
sensor calibration problem that enables the air bags to inflate even under
normal conditions on paved roads (perhaps an object bouncing up against the
underside); the fix involves a little software reprogramming.  The Cadillac
air bags can deploy when there is moisture on the floor under the driver's
seat, where the computer is located.  A fix might involve waterproofing the
computer box.  [Source: AP item, 14 July 1998, PGN Abstracting]

  [Cadillac year typo fixed in archive copy.  PGN]

Jamming devices to cut noise pollution in Japan?

Keith Rhodes <>
Tue, 14 Jul 98 07:05:44 -0500
In response to a widespread Japanese annoyance with other folks' mobile
phones, Japanese entrepreneurs are marketing mobile jamming devices that can
be used to silence those other folks.  Because "regulators are concerned
that such equipment could be misused", there are proposals to limit the use
of the jamming devices to areas in which the phones could cause significant
disturbances — such as movies, restaurants, and offices.  (There are now 30
million mobile phones in Japan, one for every three people.)  [Source: an
article by Jonathan Watts in *The Guardian*, Scripps Howard News Service, 31
Jul 1998; PGN Stark Abstracting.  Perhaps the jammers can deploy air bags?]

Russia nearly launched nukes in '95

"John P. Wilson" <>
Sun, 12 Jul 1998 22:54:48 -0400 (EDT)
A Norwegian weather research rocket was mistaken for an American Trident
ballistic missile in 1995.  This was due to "the poor state of the [Russian]
early warning systems."  After the missile was spotted, a ten-minute
countdown began toward a retaliatory strike on the US.  The Strategic Rocket
Forces were commanded to get ready for the next order, which would have been
the launch order.

jpw very stark abstracting]

John Wilson —

More satellite problems

Bleeding Edge BS CSE <>
Sun, 12 Jul 1998 08:33:28 -0700
Subsequent to the 19 May 1998 failure of the PanAmSat Galaxy IV HS601 Hughes
satellite (RISKS-19.75-78,81,84), Hughes Electronics Corp. is also
investigating two further malfunctions of HS601 satellites:

 * On 13 June 1998, the primary control processor of Galaxy VII failed,
causing service problems for several hours for several cable-television

 * On 4 July 1998, a spacecraft control processor failed aboard a satellite
used to beam broadcasts to 3.7 million U.S. subscribers of DirecTV, the
185-channel direct-broadcast satellite TV service also owned by Hughes.

In both cases, they were able to switch to a backup processor.  [Sources:
Reuters and Wall Street Journal, 9 Jul 1998, courtesy of Joan Brewer; PGN

Possessing fake IDs soon to be a federal crime

Declan McCullagh <>
Fri, 10 Jul 1998 12:43:27 -0700 (PDT)
Proposal to Make Fake IDs a Federal Offense
By Declan McCullagh ( / The Netly News, July 10, 1998,2334,13979,00.html

Remember when your underage friend ginned up that fake driver's license to
go bar-hopping? Soon it may be a federal crime, punishable by serious fines
and up to 15 years in the slammer. The Senate Judiciary Committee yesterday
unanimously approved the "Identity Theft and Assumption Deterrence Act," a
clunkily named bill that bans obtaining, possessing or using ID "other than
that issued lawfully for the use of the possessor."  [Remainder snipped.]

Cisco backs backdoor for Internet wiretaps

Declan McCullagh <>
Tue, 14 Jul 1998 10:03:11 -0700 (PDT)
Cisco Backs Backdoor for Internet Wiretaps
By Declan McCullagh (
[ / The Netly News  14 Jul 1998],2334,14025,00.html

Yesterday Cisco Systems announced a new plan to include "private doorbells"
in its routers. The company says it's a great way to protect everyone's
personal information on-line. So why are privacy groups crying foul?

The approach made public yesterday by 13 of the largest technology firms
will lead to an Internet that's easily wiretappable — it's the on-line
equivalent of the reviled Digital Telephony (CALEA) law planned for the
phone system.  [...remainder snipped...]

Y2K as a necessary event: Contingency plans needed

Sun, 12 Jul 1998 22:41 -0400
In my ongoing role of being the naive* contrarian ....

I'm concerned about all the Y2K discussion that focuses on prevention and
little, if any, discussions of contingency plans. This represents a basic
misunderstanding of how to deal effectively technology. I use the term
"ballistic automation" for the clockwork-like model of automation in which
one sets up all the rules and the system just runs without ongoing
intervention and tweaking.

In any system, there will be surprises and failures. While prevention is
great, it is never complete. Instead one must prepare for failures. We must
assume that there will be pervasive Y2K failures. The question is how do we
survive and recover from them. Such planning has a higher value than Y2K
prevention in that they basis for resilience that can deal with failures in
general and, as a side benefit, provides better security since security
breaches are simply failures.

And Y2K is only one of many problems. There are many limited-size fields
including other clocks (like the Unix one due to expire in 2037?)

Systems do not deal with events that are unanticipated and have difficulty
with those anticipated but not experienced.

One simple example the response zip code changes. Read
for more on the zip code changes in the Boston area.

It took years for phone systems to learn to deal with area code changes and
generalized area codes. But no one has heard of a zip code change. When I
provide my new zip code on e-forms, it gets rejected by systems that do
checking. Even mail from the Post Office itself uses the old zip code. Not
only is the zip code changing but it will be recycled within a year or so!
Hopefully, unlike the phone network, I'll still be able to get mail in the
future since the Post Office does have some resilience in that it tries to
handle failures with manual intervention (for now). But the more general
principles of systems design need to percolate from what we've learned in
designing systems into more the more general awareness of design issues. The
zip code system, for example, was designed without leaving extra zip codes
for future growth!

While on the topic of the Post Office, there was another article
about the consequences of unreliable delivery. The concept of end to end vs
link level reliability is something we've learned in the design of computer
systems <>. Again, this experience
needs to feed back into low tech systems.

There are indeed risks of technology. But there are also risks of
nontechnology. We must understand the risks but shouldn't be naive to assume
that we can choose a risk-free path. And we must learn that we only anticipate
some changes and need to "shake out" systems periodically. Just like we've
learned that value of forest fires, Y2K might help in clearing out the

* I'm not really that naive, but a nonnaive discussion that goes into all the
issues would be too long and boring for this forum.

Re: Key management and Alan Davidson's message (RISKS-19.84)

Stephen Kent <>
Wed, 8 Jul 1998 15:45:26 -0400
The Reuter's article, portions of which Mr. Davidson posted, is an
inaccurate characterization of the work and the outcome of the Technical
Advisory Committee to Develop a Federal Information Processing Standard for
the Federal Key Management Infrastructure (TACDFIPSFKMI).  The committee did
not set about to "design a federal computer security system that includes
"back doors.'" Rather, the committee worked to develop a FIPS that would be
used to evaluate the security functionality, assurance, and interoperability
of key recovery systems.  The document is quite policy neutral, addressing
only technical aspects of evaluating such systems, not necessarily endorsing
their use.  It also is technology neutral, not favoring any particular key
recovery technique. It is analogous to FIPS 140-1, the security evaluation
criteria for cryptographic modules.

To say that the committee "failed" is an oversimplification.  We did not
complete the FIPS and we advised the secretary that the document, in it's
current form, was not ready for public review, the next phase in the FIPS
development process.  Since we stopped work in the middle of the document
review process, we knew there were internal inconsistencies that needed to
be resolved.  However, our experience with the review process suggests that
these problems can be resolved.  In the letter, the committee noted that it
had made significant progress in its efforts and that committee members were
willing to continue work on the document.  Many expressed a belief that the
document could be successfully completed.

Steve Kent, Chair, TACDFIPSFKMI

Re: Vendors unite against bad applets (Edupage, RISKS-19.84)

Li Gong <gong@games.Eng.Sun.COM>
Tue, 7 Jul 1998 21:30:26 -0700
It is incorrect to refer to all mobile code using the term "applet".  It is
also incorrect to lump Java together with ActiveX — they have vastly
different security potentials.  Moreover, this announcement is confusing
viruses with anything that travels.  In fact, the Consortium appears to be
quite ambitious, in that mobile code basically includes anything that causes
something to happen at a remote site — the code does not actually have to
travel to have the mobile effect.  The following are all examples of "mobile
code" under this definition:

zip drive
Lisp code
Java applet
Word document
agent software
browser plugin
postscript file
removable storage
ActiveX components
articles posted to newsgroups
any number of scripting languages
attached e-mail components (MIME)
floppy disk (demo disks you receive in the post)
someone over the phone asking you to run a program
... (the list goes on and on)

It is great that the anti-virus vendors are committed to address all these
problems.  Some rudimentary questions will be, how many of these do not
consider security, which has hopeless security, and which has the best
security architecture so should be the least to worry about.

Li Gong, Java Software Division, Sun Microsystems

Re: Defining the line between hacking and web surfing (RISKS-19.84)

Michael Hogsett <>
Wed, 08 Jul 1998 12:03:38 -0700
I would think about it this way.  If I were to put a box in my front yard
with a sign that said free information, and in it I accidentally put my tax
return, how could I blame someone for reading it.  It is my fault for making
the mistake.  I feel the same way about web sites.  If they serve it, I can
read it, period.  If they do not want me to read it, they should not serve

I feel that by installing a web server the webmaster is responsible for the
content which it serves.  If I am able to get the server to give me
information that was not intended to be served that it is not my fault.

For example, some sites on the net serve image databases, such as stock
photography.  Often the images will be given sequential names, such as
k014.jpg, k015.jpg, etc.  Frequently the sites will have several examples on
the web page from the image database.  If I then make sequential requests to
the web server for files which were not linked to from the page, such as
k001.jpg, k002.jpg, etc., and the web server gives them to me then clearly
the webmaster needs to rethink how the web site is organized.  I don't think
that it is my fault for requesting, then subsequently retrieving the images.

I wrote a 55 line perl program which does just this.  It makes requests to a
webserver for a sequential list of filenames, and if it gets the expected
response ( eg not "404 not found" ), then it saves the file.  Am I hacking or
am I optimizing my web surfing time through automation?  I like to feel that
I am saving time.

Michael Hogsett

Risks of trying to filter spam from newsgroups

Ben Klausner <>
Wed, 8 Jul 1998 13:01:30 -0500 (CDT)
I've found that one of the most effective filters in my KILL file for
reading newsgroups is one that requires all subject lines to have at least a
single lower case character. Any message whose subject is in all caps is 90%
likely to be spam, and 10% likely to be from someone who thinks is message
is much more important then the rest of us do.

Unfortunately, the one kink in this is reading comp.risks, which posts all
of its subject lines in all caps. I hope this isn't telling us something. ;)

Risks of trying to filter spam from newsgroups

RISKS List Owner <>
Wed, 8 Jul 98 13:07:35 PDT
Thanks to Ben's inspired prodding, I have changed the Subject: line of this
issue (and future issues as well) so that the success rate of Ben's filter
might increase a little).

I suggested to Ben that if spamsters read his RISKS posting, his filter
might no longer be as effective, but Ben thought it was very unlikely that
spammers actually might *read* anything in RISKS.  PGN

REVIEW: "Maximum Security", Anonymous

"Rob Slade" <>
Tue, 30 Jun 1998 14:51:22 -0800

"Maximum Security", Anonymous, 1997, 1-57521-268-4,
%A   Anonymous
%C   201 W. 103rd Street, Indianapolis, IN   46290
%D   1997
%E   Mark Taber
%G   1-57521-268-4
%I   Macmillan Computer Publishing (MCP)
%O   U$49.99/C$70.95/UK#46.95 800-858-7674
%P   885 p. + CD-ROM
%T   "Maximum Security"

Rather loudly promoted on the net these days, the major selling point of
this book is that it was written "by an experienced hacker."  Supposedly one
who spent some time as a guest of Uncle Sam for fiddling bank machines.
(Some of what we are told about the author does not fit with the contents of
the book, but then, as an old professional paranoid, I may be unduly
suspicious.)  Leaving aside questions of morality and definitions of the
term "hacker," let us merely observe that these people are the gnostics.
They are the devotees of the hidden, esoteric, and arcane knowledge.  Such
knowledge, of course, is cheapened and weakened by being revealed.  Which
may explain a certain reticence on a number of points in the book.  The
introduction makes this mindset clear: Anonymous assumes that if you will
not work diligently at his direction you do not deserve to secure your
system.  One can almost feel his glee at the expectation that thousands of
sysadmins around the world will be wracking their brains and flooding Usenet
with discussions of the significance of his clues to the vital encrypted
message he has hidden on the CD-ROM.  This does, of course, presume that his
direction, and the contents of the book, warrant the effort to try and guess
his riddle.

Part one might be characterized as a social background to security.  Chapter
one is essentially an extension of the introduction, continuing to try to
convince the reader that the book is worthwhile.  But it also states that
the author wishes to raise the awareness of security in the general public.
I rather doubt that this will be the book to do so: the average user will be
put off by both the size and the subtitle's emphasis on Internet sites and
networks, neither of which the average user will run.  The (very verbose)
sales pitch continues in chapter two with rather generic promises of the
goodies offered to all manner of readers, and a list of chapters to come.
(Of course, nudge, nudge, wink, wink, some unethical people might use this
information for cracking, nudge, nudge, but none of *us* upstanding people
would do that, right? wink, wink) Having been rather careless with the term
"hacker" up to this point, chapter three belatedly attempts to distinguish
between hackers and crackers.  It doesn't succeed very well, being a pretty
faint-hearted try.  Chapter four lists a number of security penetrations in
an bid to prove that anyone can be attacked.

Part two moves into more of a technical background to security.  Chapter
five looks at the complexity of current network systems and other factors
militating against safety.  A brief introduction to the TCP/IP protocol
suite is given in chapter six.  Chapter seven gives some random material on
the Internet, programming, and UNIX.  A variety of Internet problems are
briefly mentioned in chapter eight.

Part three looks at a number of the more common security penetration tools.
Chapters nine through fourteen discuss scanners, password crackers, trojans,
password sniffers, identity tools, and malicious software respectively.
Advice on how to deal with these problems varies in depth, but generally is
not extensive.  As only one example, the author does recommend that Web
browsers be set to alert the user when a cookie is being set, but fails to
give the slightest indication of how this is to be accomplished.  The
section on viruses is the book in miniature: not necessarily *all* wrong,
but overly verbose, lacking in insight, and missing those points that would
really be helpful to the computer user or manager.

Part four reviews a number of operating system platforms.  Chapter fifteen
presents the concept of vulnerabilities (termed as "holes").  In spite of
the fact that MS-DOS, Windows 3.x, and Windows 95 have no appreciable
security, chapter sixteen lists a large number of security penetration
programs for them.  (It also has a rather odd reference demonstrating that
the author does not actually understand how the CMOS password functions
work.)  Chapter seventeen does contain a collection of the more common
suggestions for securing a UNIX box.  Tools for breaking Novell NetWare are
displayed in chapter eighteen.  Cracking tools for VMS are listed in chapter
nineteen.  Chapter twenty has both cracking and some protection software for
the Mac.  The installation of the Plan 9 operating system is discussed in
chapter twenty one.

Part five gives some advice on what to go after when you crack a system.
Chapter twenty two suggests that root access is a suitable target.  Chapter
twenty three points out that it is easier to crack a system with partial
access or inside information.  Consultants seem to be the topic of chapter
twenty four.

Part six gives information on how to penetrate a system from outside.
Chapter twenty five looks at gathering information about the target.  Rather
obvious statements about levels of attack are made in chapter twenty six.
Chapter twenty seven is a simple review of packet filtering firewalls.  IP
spoofing is discussed in chapter twenty eight.  Telnet attacks cover a wide
range, so it is surprising that chapter twenty nine is so short.  Chapter
thirty looks at loopholes in Web page programming.

Part seven, chapter thirty one, reviews legal aspects, and for once even
mentions laws outside the US.

Basically, there is a whole lot of partial information here.  It is a handy
list of security related Web sites, but made less useful by the bulked out
verbiage between the listings.  In addition, it is rather plain to see that
there is far greater emphasis on cracking than on protection.  (After all,
how vital is it to securing your system to know the algorithm for generating
fake Microsoft software registration keys?)  All you
teenage-mutant-cyberscofflaw-wannabes might be disappointed, though: the
information is almost never complete.

copyright Robert M. Slade, 1998   BKMAXSEC.RVW   980501

REVIEW: "Windows NT Security Guide", Stephen A. Sutton

"Rob Slade" <>
Mon, 6 Jul 1998 11:20:25 -0800

"Windows NT Security Guide", Stephen A. Sutton, 1997, 0-201-41969-6,
%A   Stephen A. Sutton
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   1997
%G   0-201-41969-6
%I   Addison-Wesley Publishing Co.
%O   U$29.95/C$41.00 416-447-5101 fax: 416-443-0948
%P   373 p.
%T   "Windows NT Security Guide"

Part one deals with issues of interest to users.  Chapter one is a
conceptual introduction to security and the NT system.  The material is
informal.  This makes it easy to read, but also sacrifices completeness.
Sutton's idiosyncratic structure is weak in certain areas; for example,
reliability.  The content is also lavish in its praise of Microsoft and NT,
and seemingly unwilling to admit to any weak areas or flaws.  Accounts, and
the domain model, and reviewed in chapter two.  (Illustrations are heavily
used, and could be helpful were it not for the fact that so many have
serious errors.)  The working environment, in chapter three, holds a rather
random assortment of features but concentrates on the NT security window,
rather mystically referred to as the "Trusted Path."  (Both this term and
"Trusted Computer Base" are specific referents of the "Trusted Computer
System Evaluation Criteria" of the US Department of Defense, better known as
the "Orange Book".  Neither term is used in the specific manner defined by
the Orange Book.)  The structure of the presentation seems to be intent on
showing off, frequently querying the user before having provided the answer.
(On the other hand, one formal exercise asks whether the user should enter a
password into a specific request box on the screen, and immediately tells
you that NT does not use that request box.)  Chapter four goes into a lot of
detail on ACLs (Access Control Lists) but, in common with all too many
security books, does not present a completely clear picture of effective
rights in the case of combinations of permissions.  A number of situations
where the same user name can be handled differently are looked at in chapter

Part two involves administrative tasks.  Chapter six covers the mechanics of
domain administration quite well, but the actual planning is not dealt with
in depth.  Management of accounts is the topic of chapter seven.  Auditing
and logging is covered in fair detail in chapter eight.  Although chapter
nine is nominally about the Internet and intranets, most of the space is
dedicated to general discussions of encryption.  Details of algorithms are
minimal, and a number of the topics covered have only tangential relevance
to NT.  Chapter ten is a grab bag of topics including the Registry, system
policies, and printers.  The "Trusted Computing Base," in chapter eleven,
seems to refer to computer hardware and software assets, but the protection
of these assets is not well explained.  (One of the author's major fears
seems to be viruses, but despite a great many mentions there is little
realistic information about them in the book.)  Chapter twelve closes off
with a checklist summary of section titles from the book to this point.

Part three is a single chapter, on assessment of NT security.  Much of this
chapter is dedicated to proving that NT does not need to conform to the
"Orange Book" levels.

The stated intent of the book is to provide security information both to
users of Windows NT, and to network administrators.  In reality, users would
need "cookbook" style recommendations that could be put into practice
immediately, and which are generally missing from the book.  Administrators
need a more complete and well rounded approach to the topic, particularly
addressing vulnerabilities in NT itself (such as the built-in and well known
standard accounts).  For those with no background in security the book
provides a little knowledge.  However, note the proverbial danger of a
little knowledge, particularly in cases where overconfidence can lead to

copyright Robert M. Slade, 1998   BKWNTSCG.RVW   980513

Please report problems with the web pages to the maintainer