The RISKS Digest
Volume 21 Issue 69

Monday, 15th October 2001

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…


New class of wireless attacks
Gary McGraw
Reducing risks to hospital patients
Mike Martin
Ukraine missile apparently downs Russian airliner
Hanan Cohen
SirCam redux
Gavin Scott
A risk from Excel and Outlook
Will Middelaer
Outlook for Thanksgiving
Patrick Lincoln
Billion-seconds bug
Massimo Dal Zotto
Risks of undocumented 'standards'
Lloyd Wood
Re: Ham radios in the aftermath of 11 September 2001
Todd Jonz
Mitch Collinsworth
Re: Remote control of airliners
Alan Wexelblat
Re: Sincerely yours, *Not* Osama bin Laden?
Nick Brown
Re: TurboMedical
Dick Karpinski
Public information campaign on privacy
Ben Hutchings
Re: Hackers and others win big in Net casino attacks
R.S. Heuman
REVIEW: "The CERT Guide to System and Network Security Practices", J.H. Allen
Rob Slade
Info on RISKS (comp.risks)

New class of wireless attacks

<Gary McGraw <>>
Mon, 15 Oct 2001 08:30:07 -0400

Bob Fleck, a security consultant at Cigital, working with Jordan Dimov, has
discovered new class of wireless attacks that  can be used to gain
unauthorized access to normally-protected machines on a standard wire-based
internal network.   Wireless networks involve installation of a wireless
Access Point on a normal internal network.  This Access Point is  usually
connected to the wired network through a switch or a hub.  The attacks
discovered by Cigital are based on an  adaptation of a well understood
network attack from the non-wireless world known as ARP cache poisoning.
This  emphasizes the importance of re-considering old risks in light of new
technologies, something that is especially important in  software-based

The new class of attacks encompasses:
1) the ability to monitor and manipulate traffic between two wired
   hosts behind a firewall
2) the ability to monitor and manipulate traffic between a wired host
   and a wireless host
3) the ability to compromise roaming wireless clients attached to
   different Access Points
4) the ability to monitor and manipulate traffic between two wireless clients

Previous wireless attacks have demonstrated that wireless traffic on an
802.11b network is vulnerable to monitoring and manipulation, even when it
is "protected" with WEP encryption.  This new class of attacks discovered by
Cigital is based on abusing the Address Resolution Protocol (ARP) which
binds internal IP addresses to ethernet addresses.

Mitigating the risks of these attacks is possible.  The best fix involves
placing a technical barrier between the wireless network and the normal
wired network.  This provides only a partial solution that leaves the
wireless network in a compromised state, though it protects against the
worst of the attack class Cigital discovered.  Further risks can be
mitigated through advanced design of any and all software applications that
make use of the wireless network.

Bob Fleck ( and Gary McGraw (

For more, see:

Reducing risks to hospital patients

<"Martin, Mike" <>>
Fri, 5 Oct 2001 15:06:50 +1000

Spectacular accidents to hospital patients are always newsworthy.

Recent cases include a patient in the UK who died after the wrong kidney was
removed, and a boy killed by a flying oxygen cylinder (RISKS 21.55). But
according to Dr Brent James, Executive Director of Intermountain Health Care
in Utah, the overwhelming majority of cases of patient harm are from
mundane, and preventable, causes.

Interviewed recently on Australia's Radio National by Dr Norman Swan,
<> , James
said that of 3996 cases of moderate or severe adverse drug events that his
organisation identified over a ten year period, only 3.5 per cent resulted
from a human error. The rest of the confirmed 4155 human errors over the
period "were caught before they actually led to injury, or the patient
suffered such a minor consequence that it wasn't classified as an injury".
In other words, concentrating on human error will cause 96.5 per cent of
injuries to be overlooked.

Furthermore, James said that the majority of adverse drug events were not
reported through the voluntary reporting system on which most hospitals
depend, and indeed many are not being even recognised by patient care staff.
Using a computer-based system to detect evidence of morphine overdoses,
James found that 80 (yes, eighty) times as many events were occurring as
were being reported. By using a computer system containing information about
drugs' potential for allergy reactions, and that tailored drug doses
specifically to each patient, his organisation has been able to cut the
adverse drug event rate associated with such reactions by more than 50 per

A simple systems change in treatment of patients with congestive heart
failure in his organisation means, James estimates, that 310 lives are being
saved each year, patients who otherwise would have died.

It seems people in the health system are beginning to apply principles long
used by safety analysts in aviation and other industries. (James was a
member of the Quality of Health Care in America Committee of the Institute
of Medicine that created the 1999 report, "To Err is Human". Its executive
summary noted, "Health care is a decade or more behind other high-risk
industries in its attention to ensuring basic safety.")

The key principles in James's attack on the problem appear to be:

*	focus on injuries, rather than human errors;
*	encourage (and indeed reward) injury reporting (and protect from
*	improve systems so that it's easy to do things right and hard to do
them wrong;
*	assign accountability for safety improvement;
*	measure outcomes.

Use of computer technology is key to collecting and using data and
instituting process control to support these principles.

On top of improving patient experience and saving lives, James said, "...
the old belief that quality means spare no expense, just turned out not to
be a good model. A better model is do it right the first time. It looks like
that could save as much as 15% to 25% of our total cost of operations."

Mike Martin  Sydney <>

Ukraine missile apparently downs Russian airliner

<Hanan Cohen <>>
Sat, 13 Oct 2001 06:47:31 -0700 (PDT)

While searching for early information on the Sibir Airlines TU-154 crash,
I went to the website of Russian newspaper Pravda and was surprised to see
that they have a special section for accidents.
I think the editors of Pravda are RISKS readers!

Ukraine Admits Missile Might Have Downed Airliner

  ``The cause may have been an accidental hit from an S200 rocket fired
  during Ukrainian exercises,'' Evhen Marchuk, head of Ukraine's National
  Security Council, told a news conference to present crash investigators'
  preliminary findings.

The plane crash would be the second time in 18 months that Ukraine's armed
forces have lost control of a live missile.  Last year, four people were
killed in the town of Brovary when a rocket plowed into their apartment
block. The defense ministry denied responsibility for several days until
rescue workers found missile parts in the rubble.

SirCam redux

<"Gavin Scott" <>>
Tue, 9 Oct 2001 14:46:34 -0700

For the past week I've been receiving hundreds of e-mails from a user
apparently infected with the "SirCam" virus.

Ho-hum, old risk, nothing new.

But in this case the virus has included an interesting document scavenged
from the user's computer.  The infected machine appears to belong to a
Clinical Assistant Professor at the UCLA Department of Radiation Oncology,
and the document is a 13 page Word .DOC form titled:

  (Human Use)

and includes fields for the name, SSN, and Date-of-birth of all the
personnel involved, radioactive compounds to be used, their dosages, whether
the Principal Investigator has graduated from High School, and so on.

Fortunately in this case the document is not filled out, and the SirCam
virus is apparently "defective" in that each time it runs it is selecting
the same document to send out, but of course it's not much of a stretch to
imagine even more sensitive medical documents being sprayed across the
Internet indiscriminately.

Another example of an organization which Ought To Know Better failing in
basic security, and of the tenacity of recent viruses (or perhaps the
stubbornness of end-users) as UCLA's people have been unable to stem the
tide of e-mail from the virus five days after having been informed of the
problem (though their security people were quick to respond to an e-mail
suggesting that medical documents were being distributed).

P.S. 22 more copies of the virus arrived during the composing of this
message.  Oops, 27 now.

  [This risk certainly needs to be SirCamVented.  PGN]

A risk from Excel and Outlook

<Will Middelaer <>>
Mon, 8 Oct 2001 13:05:38 -0700 (PDT)

I stumbled across this risk when an astute coworker wondered why opening an
apparently short e-mail took an inordinate amount of time to open, even for
our slow connection to a remote outlook server.  I sent him an e-mail
composed of one short sentence of plain text followed by (what I thought
was) a two column by ten row grid of excel cells.  I put the cells into the
e-mail by highlighting them in Excel, then copying and pasting them into an

What I did not know was that the e-mail message actually contained the
entire 12,000 plus cells of the spreadsheet including formatting and
formulas.  Though it appears to contain only the 20 cells that I intended to
send him, double clicking the cells in the e-mail launched Excel, which
opened with a complete version of the spreadsheet from which I had selected
the cells to send him.  The only piece of information missing seems to be
the name of the file, as it opens with a generic name.

The risk: releasing quite a bit more information (plus structure of the
spreadsheet itself) to an e-mail recipient to whom you intended to send only
part of the spreadsheet, and the risk of an application being a bit too

(Versions are Outlook 2000 Corporate or Workgroup, Excel 2000.)

Will Middelaer <>

Outlook for Thanksgiving

<Patrick Lincoln <>>
Wed, 10 Oct 2001 07:34:46 -0700

It seems that in some versions of Microsoft Outlook, Thanksgiving 2001 is
marked as 29 Nov.  In fact, Thanksgiving is early this year, on 22 Nov.

Billion-seconds bug

<Massimo Dal Zotto <>>
Thu, 11 Oct 2001 19:56:58 +0200 (MEST)

As everybody knows, on Sep 09 01:46:40 2001 GMT the system clock of every
UNIX system made the transition from 999999999 seconds to 1000000000.  After
having survived the millennium bug we believed that the "billion seconds bug"
wouldn't happen, since the UNIX time is stored as a 32-bit integer.

I have, however, been witness of a real "billion seconds bug" that hit a
medical application distributed by a top company in the medical sector.  (No,
I won't name the company.)

On September 11, a colleague told me that he and other technicians were
having strange problems with an archiving application that was unable to
initialize new cdroms. After a quick investigation, we discovered that the
automatically generated cd label contained a UNIX timestamp that after Sep
09 01:46:40 passed from 9 to 10 characters, resulting in an invalid label
not recognized by the application that was expecting a fixed-length label.

An interesting side effect of this has been a sudden rise in orders of cd-rw
drives that were initially blamed as the cause of the problem.

Massimo Dal Zotto, Via Marconi, 141,  38057 Pergine Valsugana (TN) Italy
 ++39-0461534251  www:

Risks of undocumented 'standards'

<Lloyd Wood <>>
Tue, 9 Oct 2001 17:17:23 +0100 (BST)

Andrew Tridgell is quoted as saying of the SMB protocol

  The protocol is so incredibly convoluted and bloated and badly designed --
  there are ten ways of doing everything. You end up with these massive
  exchanges going on the wire between Windows 95 and NT, just because they
  are trying to work out exactly which sets of bugs the other guy has so
  they can figure out how to actually stat a file or find its size or date
  or something. And we've found from talking to people who work at Microsoft
  how much of a headache it is to maintain the damned thing and keep it
  secure. So, they've got to be thinking of dropping it at some stage.

As also shown by Microsoft's office document formats (RISKS passim), the
risk here is that an unpublished design with gradual increments and a focus
on implementation interoperability at all costs leads to baroque, complex
implementations, a shifting feature set, and emergent, undesirable side
effects. It's like building on sand; eventually you spend all your time just
shoring up the existing structure.

There's a lot to be said for having published, fixed revisions of documented
standards, for implementations to adhere to, in minimising such risky


Re: Ham radios in the aftermath of 11 September 2001 (Murnane, R-21.68)

<Todd Jonz <>>
Fri, 12 Oct 2001 22:28:33 -0700

In RISKS 21.68 Richard Murnane <> writes:

	> 570 Amateur (ham) Radio operators from 35 states and two
	> Canadian provinces provided auxiliary radio communications...

What Richard's message didn't mention are the numerous pressures,
particularly in the U.S., that put volunteer communications services like
these at risk.

In the U.S. the radio spectrum used for these communications is either
dedicated to the Amateur Radio Service, or shared with other services.  But
a variety of commercial interests, from cellular telephone companies to
package shippers to low earth orbit satellites operators, have had their eye
on this spectrum for quite some time and never miss an opportunity to
attempt a "land grab."  Unfortunately, sometimes they are successful.  In
this age of spectrum auctions that generate revenue for the federal
government, the amateur radio community must continually struggle to retain
its spectrum allocations.

Identical bills in the House of Representatives (HR 817) and the Senate (S
549) known as The Amateur Radio Spectrum Protection Act of 2001 would
protect these allocations.  These bills have a broad base of bipartisan
support, with 44 co-sponsors in the House and seven in the Senate.
Nevertheless, although these bills have been introduced in previous sessions
of Congress, they have never made it to a floor vote in either house.

Additional information about The Amateur Radio Spectrum Protection Act of
2001 can be found at:

RISKS readers who feel inclined to contact their Congressional
representatives in support of these bills will have my gratitude and, I'm
sure, the gratitude of the entire amateur radio community.

Todd Jonz, KB6JXT <>
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

Re: Ham radios in the aftermath of 11 September 2001 (Murnane, R-21.68)

<Mitch Collinsworth <>>
Sat, 13 Oct 2001 14:33:55 -0400 (EDT)

And the RISK that this points out is that if local government regulations,
restrictive covenants, and tenant organization rules continue to make it
more and more difficult/impossible for Amateur Radio operators to put up
antennas for their stations, the day will eventually come when this nearly
free backup communication system will no longer be available in times of

Hams have "been there" for their communities, nations, neighbor communities,
and neighbor nations in times of trouble for many, many years.  The value of
their service needs to be recognized, and their right to assemble functional
radio stations needs to be guaranteed rather than restricted.

Mitch Collinsworth, K2VD

Re: Remote control of airliners (Bellovin, RISKS-21.68)

<Graystreak <>>
Tue, 9 Oct 2001 13:09:51 -0400

NPR had a fairly extensive discussion of the alternate-control proposal.
One key element of the scheme being proposed is a weighted voting system,
with weights assigned based on degree of deviation from preapproved flight

I regret not writing down the name of the expert interviewed (though writing
while driving has its own risks :).  He seemed quite reasonable and spent a
good portion of the interview discussing possible failure scenarios.

He noted that ground facilities such as control towers and transmission
facilities are in fixed locations that are easier to secure, easier to
harden, and easier to retake in the event of hostile takeover than an
airplane cockpit.

If all else fails, the control signal could be sent from an alternate ground
site, and this is where the discussion of the deviation-from- flight-plan
algorithm came in.  In essence, if the plane's control computers received
conflicting signals (say, from cockpit controls and from a ground station)
they would give more weight to those signals closer to the original flight

The criminal acts of 11 Sep required significant deviation from flight plans
over an extended period of time.  If an order to take such a significant
deviation can be overridden by another order saying "stick to plan; fly to
LAX; land normally there" then you reduce the number of possible disaster
scenarios significantly.

Of course, this is not a total solution - we can all easily think of
sequences of events that would lead to this kind of system failing.  In
addition, the system would need good specification in order not to interfere
in standard emergency situations (onboard fire, engine failure, passenger
with heart attack, etc).  But a system of this sort raises the bar to
hijacking substantially, requiring the acquisition and use of much higher
levels of technology than simple 'box cutters.'  Such technology and
training is clearly not out of the reach of all criminals, but it is out of
the reach of most.

I am in favor of continuing investigation and testing of such systems, as
they seem more directly focused on preventing known bad scenarios.  By
contrast, most of the responses proposed so far by the FAA and Congress seem
to have little bearing on the scenarios as we understand them at this point.

Alan Wexelblat <>
CHI'02 Panels Chair 		moderator,

Re: Sincerely yours, *Not* Osama bin Laden? (RISKs 21.68)

<Nick Brown <>>
Thu, 11 Oct 2001 14:24:04 +0200

>A Filipino in Belgium ended up in jail after *receiving* a joke e-mail

It turns out on reading the article that the message in question was an SMS
text message sent on a GSM phone.  I cannot believe that the people who (in
the name of freedom of course) monitor telephone traffic are grepping SMS
messages for "Osama bin Laden", on the off chance that he signs them
himself.  But if they are doing so, I guess they're reading this too, so "hi
guys" !

Nick Brown, Strasbourg, France

Re: TurboMedical (RISKS-21.68)

<Dick Karpinski <>>
Tue, 9 Oct 2001 00:56:09 -0700 (PDT)

The RISK I noticed in TurboMedical (sm) is that it instructs the applicant
in exactly what lies to tell the FAA to get through. Thus it may be a RISK
of FAA practices rather than of the use of computers.


Public information campaign on privacy

<Ben Hutchings <>>
Fri, 5 Oct 2001 20:04:45 +0100

The UK's Information Commissioner, a part of the government with which
databases of personal information are supposed to be registered, is running
a series of poster ads encouraging people to be careful with their personal
information. For example, one ad says "When your bank rings you up asking
questions, do you ever make sure it really is the bank?"

While the message may be familiar to RISKS readers, it's heartening to see
it brought to public attention - and somewhat surprising to those of us who
consider the current government to have little regard for personal privacy.

Ben Hutchings <>

Re: Hackers and others win big in Net casino attacks (RISKS-21.67)

Tue, 02 Oct 2001 10:32:58 -0400

Your added statement to Ken Nitz' item about illegal Internet gambling
parlours ignores the simple fact that they are NOT illegal in many
jurisdictions outside the US, and that US law does not apply outside the
US. [Also, it was two of their sites that had been hacked, not one...]

An example of the latter statement is:
which is an interesting risk of publishing on the Internet where US law is
NOT accepted as primary.

R.S. (Bob) Heuman, Toronto, ON, Canada

REVIEW: "The CERT Guide to System and Network Security Practices", Julia H. Allen

<Rob Slade <>>
Wed, 10 Oct 2001 07:54:02 -0800

BKCGSNSP.RVW   20010728

"The CERT Guide to System and Network Security Practices", Julia H.
Allen, 2001, 0-201-73723-X, U$39.99/C$59.95
%A   Julia H. Allen
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   2001
%G   0-201-73723-X
%I   Addison-Wesley Publishing Co.
%O   U$39.99/C$59.95 416-447-5101 fax: 416-443-0948
%P   447 p.
%T   "The CERT Guide to System and Network Security Practices"

The preface states that the intended audience for this work is the mid-level
system and network administrator.  Actually, it uses the plural, giving the
first indication that this text is only intended for those working in very
large organizations.  Chapter one is an overview of the structure of the
book, along with a listing of some other resources, and a few general
security definitions.

Part one deals with securing or hardening computers against attack.  Chapter
two lists good practices for servers and workstations, providing basic
guidelines.  There is something of a detailed breakdown of these
conventions, as well as considerations that might be useful in policy
discussions.  However, these are not procedures, and there is very little in
the way of system detail.  The reader is advised to limit services running
on computers.  This is a good practice, but there is nothing to indicate how
to find out what services are running, nor how to limit or eliminate them
once they are found.  A number of assumptions have been implicitly made, for
example about centralized administration policy, so even the material that
is included may not be suitable for all environments.  The explanations are
reasonable, but rather pedestrian, and there is a great deal of duplication
of material (the sections dealing with limiting services running on servers
and workstations, for example, are almost identical.)  Much the same is true
of securing public web servers, in chapter three.  Some material is quite
specific (specifying the Common Log Format, CLF, for activity files) while
other recommendations are vague.  Deploying firewalls, in chapter four, is a
bit different, in that it does contain some explanation of firewall types
and architectures.  Unfortunately, this text is very brief, and is padded
out with unilluminating illustrations.

Part two examines intrusion detection practices.  Chapter five covers the
preparation and setup of intrusion detection, chapter six the actual
detection of intrusions, and chapter seven outlines responses to intrusions.
Overall, part two is more useful than part one, since intrusion detection is
a newer field, and general concepts are still helpful even if specific
details are lacking.

Given the complaints I have made about the lack of details, some will
respond that I have, heretofore, ignored the fact that there are two
appendices in the book, dealing with security implementations and practices.
True, these documents exist.  In terms of the security implementations, if
you are using Solaris 2.x, Tripwire, Logsurfer, and Snort, the additional
material may be very useful.  Otherwise, it still doesn't address the lack
of specifics in the book.

This work does provide the security specialist, faced with responsibility
for policy creation or maintenance, a handy set of checklists and some
framework for the policy process.  Use of the text will help remind the
professional of areas to be addressed, and prevent certain aspects from
slipping between the cracks.  The advanced and experienced system
administrator may also benefit from the volume, since he or she will likely
already know system specifics for a number of the functions required, and
probably has some idea of where to find information about others.  However,
intermediate sysadmins, with an "engineer" level certificate and a few
years' work experience, are unlikely to know the details of security
operations that have, usually, been seen as a specialty area.  Therefore,
the audience which will find this book to be useful is a rather narrow one.

copyright Robert M. Slade, 2001   BKCGSNSP.RVW   20010728    or

Please report problems with the web pages to the maintainer