The RISKS Digest
Volume 18 Issue 42

Tuesday, 10th September 1996

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…


Failure-mode risks revealed by Hurricane Fran
Dave Schulman
Missile passes American Airlines Flight 1170 over Wallops Island
John Maddaus
Re: Accidental shooting down of F15 plane revisited
Dick Mills
Your BASIC electrocution — "rats!", he said
Tim Steele
Black-hole web forms
Prentiss Riddle
RISK: Dangerous core dumps
Y2K - Yet another risk
John Elsbury
Re: AOL curbs incoming spams
Brian Clapper
Bear Giles
Bear Giles
Re: AOL denial of service
Peter M. Weiss
Re: Netcom denial of service
Keith Moore
Re: Windows95 Passwords
Stewart Nolan
Microsoft VC++ property pages guaranteed to crash first time
Mark Mullin
1998 USENIX Security Conference, announcement/call for papers
Aviel Rubin
Info on RISKS (comp.risks)

Failure-mode risks revealed by Hurricane Fran

Dave Schulman <>
Mon, 9 Sep 1996 18:10:04 +0000
Having just survived a hellish weekend due to Hurricane Fran here in North
Carolina, I found it interesting that several technological RISKS have only
now come to light.

The area was clearly unprepared for a disaster of this magnitude, and is now
paying the price for the "can't happen here" complacency apparent in the
local utilities' failure to take preventive action which could have greatly
reduced the suffering now happening here.  Specifically, the electric
utilities (and, by extension, their customers) have thus far resisted
modernization in the form of buried power lines; presumably the rate
increases necessary to finance this are anathema to existing customers.  The
lack of attention to trees growing close to power lines has now borne fruit,
so to speak; about 100,000 subscribers have been without electricity for
over three days, as of this writing.

For what it's worth, I'm a recent transplant here myself, after having lived
for nineteen years in South Florida, where hurricanes are an established
fact of life and building codes are strict enough to persuade most designers
to do the Right Things.

The Risks Forum has had much discussion in the past of the engineering of
critical and safety systems, and how they should be designed to fail in a
"safe" mode.  It turns out that this design principle was lost on the people
who designed the apartment complex in which I live.  This complex contains
electronic card-access locks with no manual overrides, and a "security" gate
which fails into a "lockdown" mode.  This is the sort of "safe" mode which
might be appropriate for a prison, but certainly not for the only
entrance/exit for a residential community.  Had a fire broken out in the
wake of the storm, I would very probably not be here to write this.

This complex is also provided with a so-called "security system" which is
automatically hooked into each unit's telephone line.  In the event of a
power failure, these systems attempt to dial their monitoring stations to
call for service.  There is apparently no time-out interval for this; these
alarms simply seized all affected phone lines and effectively kept them out
of service until their backup batteries ran down after eight hours or so.
This means, of course, that a power failure also guarantees loss of
telephone service (for eight hours, anyway).

The RISKS here are all too depressingly obvious.  It's a near-miracle that
more people did not have to pay with their lives for such embarrassing lack
of foresight.

Dave Schulman, Nortel, Inc., 400 Perimeter Park Drive, Morrisville, NC 27560
Validation Engineer, Feature Test I  (919) 905-4844; (919) 905-2549 (FAX)

Missile passes American Airlines Flight 1170 over Wallops Island

"Peter G. Neumann" <>
Mon, 9 Sep 96 14:14:12 PDT
>From: (John S. Maddaus)
>Newsgroups: rec.aviation.military
>Subject: Another missile/airline incident
>Date: Sun, 8 Sep 1996 14:33:04 GMT
>Organization: GTE Labs Inc
>Message-ID: <>
>Xref: rec.aviation.military:106911

The *New Hampshire Sunday News* [8 Sep 1996] is reporting that at 1:45pm 29
Aug 1996 American Airlines flight 1170 was flying over Wallops Island,
Virginia, en route from San Juan to Boston when the captain reported
(apparently only to the company at the time) "a missile off the right wing".
The report has been confirmed by the NTSB, which has assigned an
investigator.  Apparently, the FAA is investigating on its own as well.  The
paper goes on to mention the proximity to Wallops Flight Facility with
nearby Navy installations at Norfolk and Lexington Park.

I'm assuming that normal cruise for the 757 would put it out of range of
surface-to-air portables and there is no way to infer the trajectory based
on what was said in the paper.  However, note the headline "American
Airlines Pilot Says Missile Zoomed by His 757", which is not what the quote
above relates.  [Not surprising.  Headlines often have little to do with
articles, because they are written by a headline specialist.  John's
subsequent comments, speculations, and questions have been omitted for

John Maddaus

  [Wallops Island has long been a rocket launching facility.  Over 9 years
  ago, RISKS-04.96 reported the case in which a lightning strike on the
  launch platform ignited three rockets and accidentally launched two of
  them.  NASA had been intending to test launch capabilities in the presence
  of lightning storms.  PGN]

Re: Accidental shooting down of F15 plane revisited (RISKS-18.41)

Dick Mills <>
Mon, 09 Sep 1996 00:31:49 -0400
Regular RISKS readers may remember several earlier articles about this
incident that seemed to lay the blame on software bugs.  Now, we hear a
different story entirely and the cause is alleged to be something completely
different.  [Note that a single person, Chiaki Ishikawa, has simply reported
the sequence as it arose.  See RISKS-17.65, -18.18, and -18.41.  PGN]

There is a risk that occasional readers or researchers using search engines
may come across the archived RISKS articles and use them to prove a point,
or merely to sensationalize.  They might never find the later articles that
set the record straight. This is not a criticism of RISKS, but rather an
attribute of any ongoing public discussion on the Internet.

There is also a new element to the risk. The resources needed to search
massive amounts of news archives was, until recently, only affordable to
wealthy organizations.  Now we can all do it inexpensively, but most of us
aren't trained investigators or journalists.

I believe that we should make airplane accidents a special case, and to
voluntarily withhold public discussion and speculation until the accident
report is in.  Not forever, but until the reports are in and read.

There are several reasons why just airplane disasters are exceptional.

a) Early speculations about why the incident occurred are frequently wrong.

b) The actual report, issued after all the physical and other evidence
   has been examined, will be available within a reasonable time (months
   to one or two years.)  There is ample opportunity to challenge
   the report's conclusion or offer other opinions after its release.

c) Speculations are often highly technical.  This may lead non-technical
   people to ignore what is actually said as not understandable, and to
   look only at the headline and the source. RISKS is a respected source
   and some people may believe anything they read here is authoritative.

d) The sensational nature of air disasters makes the public and the media
   hungry for any tidbits.  Technical debates intended for a closed
   audience aren't likely to stay closed for long.

e) Speculation may cause additional grief for the families of victims and
   crew or others involved.  Reputations can be ruined.  Even when the
   speculations prove true, the full report can include mitigating details
   that color one's judgement differently than partial information might.

Pilots in the hanger engage in gossip just like anybody else.  When an air
disaster occurs, you can bet the gossip flows freely.  However, it is
considered bad form to do so within earshot of laymen.

No doubt there are other risks that also deserve sensitive treatment, but to
me airplane disasters stand out most clearly.

Dick Mills

  [It is intriguing that there are perhaps a dozen books on the KAL 007
  case.  It is not surprising that theories proliferate during times
  that definitive reports are not available, but it is also not surprising
  that, even with the presence of supposedly definitive reports, different
  theories continue to propagate indefinitely.  The TWA 800 case may become
  another example.  You may note that RISKS has been silent on that case,
  eschewing speculation; however, there are some rather startling hypotheses
  floating around.  PGN]

Your BASIC electrocution — "rats!", he said

Tim Steele <>
Tue, 10 Sep 1996 14:26:01 +0100 (BST)
The euthanasia-via-computer story in RISKS-18.05 reminds me of an anecdote I
was told by a colleague in a previous job.  He once worked for a
pharmaceuticals firm and was required to find out if a particular candidate
molecule had any potential as an anti-anxiety drug.  He rigged up a set of
cages for a number of rats, each of which could be warned (by a light, or
something) and shocked (by wires in the floor of the cage).  The idea, as I
recall, was to warn the rats, then shock them briefly over a period of time
to see if the light alone subsequently caused the same amount of agitation.
If the drug was effective, it should make the rats less anxious (move around
less) when the light came on.

Unfortunately, the software he had written (in interpreted BASIC) had the
undesirable feature that, if it stopped due to a runtime error, the output
states [*] would remain as they were.  During the night, the program hung
during the "shock" routine, and when he came in the next day all the rats
had been comprehensively electrocuted [*].

  [* Rat-etat(s), especially if they were French rats?  PGN]

Black-hole web forms

Prentiss Riddle <>
Tue, 10 Sep 1996 10:09:11 -0500 (CDT)
This week I had the frustrating experience of trying to register for a
conference using an online form that provided no feedback.  I'll omit the
name of the conference to protect the guilty.  (The conference is web-related,
so its organizers really should know better.)

The HTML form used the "mailto" action to deliver user input via e-mail
rather than feeding it to a CGI program.  Not only is "mailto" not supported
by all web browsers, but it has the unfortunate feature of not providing any
feedback to the user that the form has been submitted.  In contrast,
well-written CGI transaction handling programs will provide an
acknowledgement screen and/or acknowledgement by e-mail (and very
well-written ones may provide an encrypted electronic "receipt" as well).

The risks of online transactions that lack immediate feedback?  User
confusion and anxiety over whether the form was really submitted and the
transaction really took place; redundant submission of forms as users
re-submit in expectation of feedback; multiple transactions (e.g., multiple
charges to the user's credit card) unless the back-end system has a
bulletproof way to detect duplicate submissions; possible *non*-execution of
transactions if the user's web browser really didn't catch the click on the
"Submit" button and the user has been trained to expect no feedback; and
wasted time and money as the user gives up on the online transaction and
tries to straighten it out by telephone.

I do have some sympathy for small organizations trying to carry out
transactions on the web without a prohibitive investment of resources.  The
marketplace for online commerce software is extremely chaotic right now, and
do-it-yourself CGI programming is considerably more complex than learning to
slap HTML tags into a document.  But as the web moves from being a
publishing system to being a more comprehensive system for commerce and
other kinds of transactions, it is important that the people who set up
online transaction systems recognize that their attention to reliability and
user interface design must increase accordingly.

Prentiss Riddle

RISK: Dangerous core dumps

Abigail <>
Fri, 06 Sep 1996 22:00:42 +0100
The following happened to me about a year ago:

Wanting to ftp a file to a remote server, I accidentally used a telnet
client instead of an ftp client. Confused about the presented interface, I
managed to type in some commands that crashed the ftp server on the remote
site, dumping a core file.

A little later, I found the core file in my directory, and for no other
reason than shear boreness, I loaded it into a textfile. Removing all the
control chars, I suddenly looked at a string that was all very familiar to
me: my password.

It turned out the send password was stored in a variable which was allowed
to live too long. (It got quickly fixed.)

I don't think I need to explain about the risks.


  [This is a very old risk, but worthy reiterating for younger readers.  PGN]

Y2K - Yet another risk

John Elsbury <>
Tue, 10 Sep 1996 13:41:00 +1200
A British insurance company is reported to be providing a new insurance
policy.  They have been offering an "Alien Impregnation Policy", which is
said to have sold 300 policies in a week: fired up by their success, they
are now offering a "Virgin Birth" policy, on the grounds that a number of
women are worried about the millennium.  However, religious authorities are
said to be cool towards the idea.  (Since one of the larger organised
religions depends on just such a manifestation of the Holy Spirit, this
seems on the face of it inconsistent.)

This makes the Y2K computer-system date risks appear almost trivial.
The market may be limited however — a straw poll of female colleagues
indicated that this was the last thing on their minds at the moment.

  [It will be interesting to see what evidence will be required for insurance
  claims on an Alien Impregnation Policy.  I presume this will be a classic
  challenge for computerized DNA matching, and a glorious opportunity to
  become famous for the lab technician who first identifies alien DNA,
  or its equivalent!  PGN]

Re: AOL curbs incoming spams (PGN, RISKS-18.41)

Brian Clapper <>
Fri, 6 Sep 1996 15:32:57 -0400 (EDT)
According to today's on-line Philadelphia Inquirer
(see `')
U.S. District Court Judge Charles R. Weiner filed a temporary restraining
order against AOL, ordering it to stop blocking junk e-mail sent by
Cyber Promotions Inc.  [The trial is scheduled for midNovember.]

Brian Clapper

Re: AOL curbs incoming spamming (RISKS-18.41)

Bear Giles <bear@eris>
Sun, 8 Sep 1996 01:14:40 -0600
[...] Undoubtedly, the plaintiffs cited _Consolidated Edison v. Public
Service Commission, 447 US 530 (1980) in the injunction.

In the Supreme Court decision, the Court said that our right to be
bothered does not justify limiting First Amendment rights.  The solution
is "[simple as] transferring [it] from envelope to wastebasket."
[_Sex, Laws and Cyberspace_, 1996, pg 36]

The obvious counterpoint is that the US Postal Service is a "universal"
service which is legally mandated to attempt delivery to all residents.
With few exceptions (based on geography), receiving a letter requires no
prior setup by the individual.  Nor does the individual have to pay a
monthly charge for access to his mailbox (in contrast to the _rental_ fee
for those boxes located in a post office).  Nor does the individual have to
sign contractual agreements with the postal service regarding issues such as
"appropriate use" of the mail.  (There are postal laws, but many
"appropriate use" restrictions are more restrictive.)

In contrast, online service providers require a "setup" before they'll
accept e-mail for an individual.  They charge for access to the mail boxes.
And nearly all providers require users to agree to various "conditions of
use" before the user can access his mail box.

These differences may not be enough to directly challenge the court's
reasoning in the prior case, but it's enough to challenge the assumption
that the matter has been definitively resolved.  In 1980 the USPS was the
sole mail delivery agent for the vast majority of Americans; it was also
(until recently) literally a branch of the federal government.  Today we
have e-mail, fax/modems, FedEx, etc., all independent of direct government

As a wild-eyed extrapolation, this case may kill the attempts by the USPS to
form its own e-mail service.  If it's ultimately decided that private ISPs
can block spammers while the USPS (as a quasi-government agency) can't, few
people would choose the spammed version if they had an alternative.

Bear Giles

Re: AOL curbs incoming spamming (PGN, RISKS-18.41)

Tue, 10 Sep 1996 02:56:04 -0600 (MDT)
>From what I gathered while scanning an article at lunch today, the spamming
company had _1.5 million_ AOL e-mail addresses.

Assuming a typical message of 2k or so and a typical target of only 1% of
the AOL subscriber base, the effects on AOL mailers could still be best
described as "mail bombing."  (15,000 messages totaling 30 MB).

Assuming the typical user has 2-3 messages in his inbox at any time, the
total amount of disk space wasted on spams is 6-9 _Giga_bytes, at best.  In
practice, with a distributed architecture the additional disk space (used or
unused) required might easily total 20+ GB.

Another important factor to consider is the cost to backup an extra material
in user's mailboxes.

The cost per AOL user is still modest, but why is it borne by AOL users, and
not the party sending the unsolicited mail?  (The sender of physical mail is
always responsible for postage.)  And what happens when it's not one company
sending mail to 1.5 million subscribers, but a thousand direct marketers?

Bear Giles

re: AOL denial of service (Birsa, RISKS-18.41)

"Peter M. Weiss +1 814 863 1843" <PMW1@PSUVM.PSU.EDU>
Tue, 10 Sep 96 08:36 EDT
Perhaps this subject is better thought of trying to make a silk purse out of
a sow's ear?  If you are going to put your reputation on (the) line via
contracting with an Internet Service Providor, then it behooves you to have
a service level agreement with them.  Assuming that they are going to
provide the service that you silently expect does not seem like a wise
business decision to me.

Pete Weiss at Penn State

Re: Netcom denial of service (Lindahl, RISKS 18.41)

Keith Moore <moore@CS.UTK.EDU>
05 Sep 1996 22:08:38 -0400
Greg Lindahl <> writes about auto-responders that
bounce messages with Precedence: {bulk,junk} and ignore the Errors-To header
field, and admits that "writing correct mail handling programs is complex."

In fact, the situation is even more complex than that.  Both fields
are undefined, nonstandard, and can cause incorrect mail handling.

Use of the Precedence field varies widely.  It was originally used by
sendmail to determine queueing priority and more recently, to determine
whether a nondelivery report returns the subject content.  Some vacation
programs use it (among other heuristics) to determine whether to respond to
a message.  Some X.400 gateways use it to encode the X.400 Priority field,
and return as nondeliverable any message that contains an unknown Precedence
keyword.  Some mailing list expanders use it as a means to prevent loops
between peered lists, and therefore refuse to forward any message with
certain Precedence values to the list membership.

As a result, there is no value for Precedence that is recognized by
vacation, which does not result in mail delivery failure for some set of

Use of Errors-to violates a long-established (since 1980) standard which
indicates where to send nondelivery reports.  Within SMTP, they go to the
MAIL FROM address, and mailing lists are required to set the MAIL FROM
address to their list maintainer when distributing mail to the list
membership.  Outside of SMTP, nondelivery reports go to the address in the
Return-Path field, which is set from MAIL FROM when the mail leaves the SMTP
world.  Some lists set Errors-to without setting the MAIL FROM address, some
set only MAIL FROM, and some set both.  MTAs that comply with the standards
ignore Errors-to, but others use it to override MAIL FROM.  Still others
send nondelivery reports to both addresses, which in the worst case can
cause a form of sorcerer's apprentice syndrome.

In fact neither field belongs in the message header while the message is "on
the wire".  Queueing priority and error return addresses are both the
concern of the message transport layer (e.g. SMTP), while the message header
is intended only for use by the user agent.  MTAs are supposed to ignore
message headers, but instead they end up affecting whether a message gets
delivered.  And since these fields appear visibly in much list traffic,
there is a widely held perception that they are correct protocol.

Plain-text protocols are easy to implement and debug, but they create
the RISK that users will think they understand the protocol, and
attempt to implement it without reading the specifications!

Keith Moore                    
Computer Science Dept. / Univ of Tenn / 107 Ayres Hall / Knoxville TN 37996

Congress shall make no law respecting an establishment of religion, or
prohibiting the free exercise thereof; OR ABRIDGING THE FREEDOM OF SPEECH,
or of the press; or the right of the people peaceably to assemble, and to
petition the government for a redress of grievances.

- Amendment I, US Constitution (emphasis mine)

Re: Windows95 Passwords (Giles, RISKS-18.41)

"Stewart Nolan" <>
Tue, 10 Sep 1996 10:08:11 +0100
>Windows 95 allows you to specify one password on the system... and changing
>the password on the Win95 screensaver does _not_ require verification with
>any system-wide or user-specific passwords.

Having used this OS for about a year now, I find that it does not have a
particularly secure setup.

If windows is waiting for a user login, there appear to be two ways around it:

1. Click OK.
When windows again prompts for the password, click cancel.

This seems to have the effect of logging the user in at the highest possible
level if there are multiple users of the system, otherwise the user is
logged in as the common user. From here it is simple enough to run regedit,
causing all manner of havoc.

2. Press the windows key, or Ctrl-Esc if there isn't one.

This brings up task manager, again with the ability of running regedit from
the command line.

The only way I have seen around this is to disable the login box (change the
primary login to Windows), which will circumvent the appearance of the login
dialogue. Unfortunately, this means there can be only one user, and if there
is only one user, it isn't sensible to remove Registry editing tools.

Enable passwords at bios level, and switch it off when you leave your
machine, for optimum security. Oh, and don't use win3.1x screen savers, they
can be skipped by Ctrl Alt Del.

Stewart Nolan

Microsoft VC++ property pages guaranteed to crash first time

Mark Mullin <>
Fri, 06 Sep 1996 13:57:06 -0700
Microsquish Stealth Bug Insertion Technology

While I'm kind of dismayed by the "if you can't innovate, litigate"
philosophy so often applied to Microsoft, this is a particularly lethal
little gem from their MFC team.  In many development environments, this
problem will almost certainly guarantee that your app will crash the first
time it is executed on customer machines, but the crash will only happen
once, and will mystify tech support.

The problem arises in the use of property pages, otherwise known as tabbed
notebook dialogs, as they are designed and implemented in the Visual C++/MFC
environment.  VC allows the developer to use interactive resource editors to
design the property pages, but IT ONLY DOES THE FINAL STEP OF THE PROCESS IN
EXECUTING THE APPLICATION, not in the development cycle.  This step, where
the style of the page is changed in the resource will cause most machines to
abort the software as it is attempting to change a read only resource.

What really concerns me from a risks perspective is that the traditional
development model is to release an exe to the test/qa group, and then to
ship this exe to production when it receives a blessing from test/qa.  This
means that the exe shipped to production IS NOT THE SAME AS THE ONE THAT WAS
TESTED, because the tested exe has been executed, and the one sent to
production has not.  Hence, every customer who launches the app for the
first time will be rewarded with a crash, which can never be reproduced.

Yes, you can get around it with careful use of filtered exceptions.  The
problem is that this is rather insidious, and outside the realm of thinking
of most developers, who view an exe as the final product of the development
process.  In this case, the final product is an executed exe.

Personally, I feel this is a lot like the Monty Python "Frog chocolates"
sketch.  VC too should have a great big warning sticker on it saying "An EXE

  — -- — -- — -- ORIGINAL MICROSOFT DOCUMENTATION    — -- — -- — --
Applies to class CPropertyPage, specifically the DoModal function that
causes the page to be presented on the screen.

virtual int DoModal( );

  [... standard usage documentation deleted...]

Note.  The first time a property page is created from its corresponding
dialog resource, it may cause a first-chance exception. This is a result of
the property page changing the style of the dialog resource to the required
style prior to creating the page. Because resources are generally read-only,
this causes an exception. The exception is handled by the system, and a copy
of the modified resource is made automatically by the system. The
first-chance exception can thus be ignored.  Since this exception must be
handled by the operating system, do not wrap calls to
CPropertySheet::DoModal with a C++ try/catch block in which the catch
handles all exceptions, for example, catch (...). This will handle the
exception intended for the operating system, causing unpredictable behavior.
Using C++ exception handling with specific exception types or using
structured exception handling where the Access Violation exception is passed
through to the operating system is safe, however.

1998 USENIX Security Conference, announcement/call for papers

Aviel Rubin <rubin@usenix.ORG>
Sun, 8 Sep 1996 07:54:12 -0700 (PDT)
7th USENIX Security Symposium
26-29 January 1998
Marriott Hotel-- San Antonio, Texas

Sponsored by the USENIX Association, the UNIX and Advanced Computing Systems
Professional and Technical Association, in cooperation with: The CERT
Coordination Center.  Papers due: September 9, 1997.  Program Chair: Avi
Rubin, Bellcore

Conference home page: <>
Detailed guidelines for submission via e-mail to <>.
or telephone the USENIX Association office at (510) 528-8649.

USENIX Conference Office
22672 Lambert Street, Suite 613
Lake Forest, CA USA   92630
Phone:  (714) 588-8649
Fax: (714) 588-9706
E-mail: <>

Please report problems with the web pages to the maintainer