The RISKS Digest
Volume 20 Issue 42

Tuesday, 25th May 1999

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 Breakdown leaves swimmers in the cold
Paul Oldham
o Professional hazard in lightning monitoring
Amos Shapir
o Airport radar comes under scrutiny
Doneel Edelson
o Hospital delivery robot blocks exit from elevator
Lyle Gray
o Y2K testing on weather images
Amos Shapir
o German government criticizes own style in Word documents
Debora Weber-Wulff
o Summary of biometric responses
Dan Wallach
o Re: Biometrics
Dave Upton
o Eye swear, it was working yesterday!
Adam Shostack
o Addressing phenomenon: Once a Canadian, ...
Mich Kabay
o Security vulnerability in Netscape
Lindsay Marshall
o Emperor Hirohito's death causes SW problems
Stuart Woodward
o Re: JAVA language definition
Jim Thompson
Robin Landis
o Microsoft "fixes" the MS Office macro virus vulnerability
Paul Walker
o Embedded NT... in case you don't have enough to worry about already
Gregor Ronald
o REVIEW: "Microsoft Windows NT 4.0 Security, Audit, and Control"
Rob Slade
o Info on RISKS (comp.risks)

Breakdown leaves swimmers in the cold

Paul Oldham <>
Mon, 24 May 1999 17:38 +0100 (BST)
Cambridge Evening News of 24th May 1999 reports the following story:

  Swimmers taking a dip in Ely's newly-refurbished Paradise Pool were
  stranded when a high-tech locker-system broke down, leaving many without
  their clothes and belongings.

  Shivering swimmers were wrapped in silver foil blankets after the incident
  yesterday, when the electronic lockers shut down after a power failure.

  People were forced to wait for an hour-and-a-half until mechanics arrived
  at the scene. Youngsters who had come by themselves were given money to
  make a call home. Free drinks and food were also handed out. New swimmers
  were stopped from using the pool, which was closed for a short time while
  the problem was dealt with.

  The system which replaces the "key and coin" scheme usually found in
  public pools means that swimmers can access their locker with a tag fitted
  with an electronic microchip.

  The new and improved leisure pool, which recently underwent a UKP1.9
  million renovation, has only been open for little more than a month.

Apart from wondering whether this risk had ever been considered by either
the designers or the people who procured this system, one is left wondering
what the benefit was on this system over the traditional key and coin
scheme, which appears to work perfectly well at many pools in the area and
has no failure mode which leaves every locker locked.

Paul Oldham, Milton, Cambridge, UK

  [Perhaps the system was designed by the Davy Jones Locker Company.  PGN]

Professional hazard in lightning monitoring

24 May 1999 13:17:00 GMT
For the past few days, the European lightning strikes charts at
are showing an empty map, with the inscription: "Due to technical reasons
(lightning strike) no lightning charts are available".

It doesn't say what part of the system was struck.

Amos Shapir, nSOF Parallel Software, Ltd., Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552

  [Reminds me a little of lightning striking the launch pad at Wallops
  Island that accidentally launched a missile that had been prepared to be
  launched in order to test the effects of lightning.  PGN]

Airport radar comes under scrutiny

"Edelson, Doneel" <>
Tue, 25 May 1999 12:03:31 -0400
For as many as a dozen times during an hour-and-a-quarter period during the
midafternoon of 17 May 1999, repeated failures in a computer processor at
the Philadelphia International Airport caused the radar-osaurus system to
fail, losing partial data associated with each flight.  The outage required
air-traffic controllers to resort to the even older paper-slip backup
system.  As usual, the official spokesperson said ``There was no impact to
safety.''  [Source: an article in USA Today, 23 May 1999, which noted that a
power failure earlier in May had caused a 23-minute outage of radar scopes
and radio contacts in the same place; PGN-ed]

Hospital delivery robot blocks exit from elevator

"Gray, Lyle" <Lyle@Quodata.Com>
Fri, 14 May 1999 18:21:07 -0400
While I was being transported by gurney to an operating room in February of
1998, a hospital delivery robot (essentially a large, automated supply cart)
met the elevator when it arrived on the operating room floor.

The robot knew that the elevator was occupied, and instructed us to clear
the way so that it could enter.  However, as the elevator had a gurney in
it, there was not enough room to clear the way.  The robot would not back
away from the elevator to let us out, and we could not close the elevator
doors to try to go to a different floor, because the doors were being
blocked by the robot.

Finally, a medical technician man-handled the robot out of the way so that
the gurney could be pushed out of the elevator, leaving it to try to figure
out its new orientation and try again.

The Risk?  Not programming the robot to allow for a situation that _must_ be
common in its environment (gurneys in elevators).

Lyle H. Gray

Y2K testing on weather images

Tue, 25 May 1999 15:29:14 IDT
There's a site at Nottingham U., UK, where weather satellite images are
received from a geostationary satellite (Meteosat), timestamped and prepared
in several different formats.  (

I download some images regularly off this site a few time a day.  One
morning last week, several images were missing; the next image available,
was timestamped "FEB 28 2000, 2330" (though it seemed to be a current one).
The next one was timestamped "FEB 28 2000, 2400".  Oh well, back to the
debuggers...  (the rest of the images on that day had their correct

Amos Shapir, nSOF Parallel Software, Ltd.,Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552

  [Perhaps they were running a Y2K leap-year experiment.  PGN]

German government criticizes own style in Word documents

Debora Weber-Wulff <>
Mon, 24 May 1999 16:42:37 +0200
My husband, a historian, downloaded a lot of official German government
documents for a talk he is preparing on reunification. Many of the documents
are in some Microsoft format or other. The most amusing one was stored in
.doc format on their web pages in the proofreading version. That is, one can
see that they have replaced all references to DDR with Ost (East), and so
on. A quick look at the properties of the file is hilarious: "The style of
this file is stilted, pompous, noun-laden, non-concise and in general not
useful. Must be rewritten!"

Interestingly enough, since no author is filled in in this field, Microsoft
decides that I, as the license holder, am the author of the document. Other
documents, for which no organisation is entered, believe that my
organisation is responsible. The moral of the story: if you are using such
products for net publication, make sure that there are no little surprises
hiding in the text!

Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin, FB,
Informatik, 13353 Berlin, Germany

Summary of biometric responses

Dan Wallach <>
Mon, 24 May 1999 19:21:16 -0500
Our esteemed moderator is up to his eyeballs in biometric responses and has
asked me to look them over and make a summary.  Here goes:

David Kinny [a] and C. Scott Ananian [b] mention possible issues with
contact lenses and object to being required to remove them.  According to
Ananian, newer contacts have both color and texture on them (for cosmetic
reasons, of course).  IriScan claims to be able to deal with contact lenses
but doesn't give precise details of how this works [1].  I would refer
readers with these kinds of detailed technical questions to IriScan's Web

Ananian discusses future generation contact lenses, which presumably will
take us further away from natural-looking eyes.  I imagine that, in the
limit (say, reflective lenses), contacts would have to be removed to make a
positive authentication.

Also writes Ananian:
> Finally, although we are assured that iris images are deleted
> immediately after processing, we all know the permanence of data on
> today's digital hardware.  If those images are swapped to disk or
> ever written to a file during processing, a thief might acquire not
> just one but *several* iris images with appropriate scrubwork over
> the magnetic media.  Combined with appropriate contact lens
> technology...
>  --s
> [note that this opens up an interesting avenue regarding the alleged
> 'irrevocability' of one's biometric; here's something I can
> (potentially) change at will, despite being an almost inseparable
> part of the vison-corrected me]

The vendors would likely claim that no contact lens will allow you to assume
somebody else's indentity and they might be correct.  However, if relatively
opaque lenses become fashionably normal, the efficacy of iris scanners would
be greatly reduced.

Steve Feinstein [c] discusses the issue of 'cloning' someone in order to
produce identical irises.  Vendor studies of identical twins show that
irises are truly personal — the exact iris patterns form as a function of
development, although certain gross features (i.e., color) are genetic.

William Leary [d] and Marcus Rowland [e] discuss scenarios whereby an ATM
user is vulnerable during the 2-4 seconds they are being scanned.  If you
hear a noise behind you, you either look around (safety first, after all)
and then restart the authentication later, or you resolutely stare forward,
allowing an assailant a known time window where you are more vulnerable to a
mugging.  Given how current ATMs requires you to stare at the screen right
now to follow their instructions, I don't think iris scanners exacerbate
this problem.

Paul Czyzewski [f] mentions a general privacy concern, i.e., that iris scanners
could be installed everywhere we currently have security cameras and might be
able to scan your "involuntarily".  This could be a big step toward an
Orwellian future.  As it stands today, the technology only seems to work under
controlled circumstances.  Unless the government bans sunglasses, you should be
relatively safe well into the future.

Finally, Mark Hayman [g] brings up the scenario where current ATMs will,
upon multiple bad PIN entries, "eat" your ATM card.  Hopefully,
iris-scanning ATMs will not employ an analogous strategy.

Dan Wallach, Rice University


  [Incidentally, Bruce Schneier makes some compelling arguments against
  biometrics, although he is obviously for strong authentication.  See

Re: Biometrics

25 May 99 10:14:54 SST
What's the Problem?

My question at the top of this still stands.  I know you can all answer that
and some of you have but when compared to what we have What is the problem?
The system we have now of easily duplicated cards with insecure PINs surely
has more proven risks than those posed by biometrics.  Sure sometime in the
future security measures for these devices may well be compromised but by
then hopefully those measures will have moved on.  Sure some people will be
"biometrically challenged" but are there not "ATM challenged" people out
there now who are missing out?

If we wait for the perfect system the waiting will never end.  There are
risks but it seems to me not as many as with our current system of cheques,
credit cards, ATM cards and PINs.

So again I ask, What is the problem?

Dave Upton

Eye swear, it was working yesterday!

Adam Shostack <>
Mon, 24 May 1999 09:26:40 -0400
One of the risks of a purely biometric system is that biometrics are
sometimes destroyed in accidents.  This is often a major concern in hospital
patient tracking systems, since most of those accidents lead directly to the
patient being brought to the hospital, where the alternate lookup method
needs to be invoked.  Interestingly, this risk is obvious to the medical
industry, because of the scenarios which they examine when designing their

I suspect that there will be alternate methods in place, if the banks
deploying have realized that having only biometrics in their ATMs may
violate the Americans with Disabilities act.

Addressing phenomenon: Once a Canadian, ...

Mich Kabay <>
Mon, 24 May 1999 11:25:36 -0400
  [From a recent letter clearly showing an Evil Plot to tar me with my
  Canadian citizenship forever:]

  Dear Dr Kabay:

  This is in reference to the note you sent regarding your address in
  Vermont.  I can understand your dismay on seeing that Canada appears in
  your address when you live in Vermont.  Our new ... system has a slight
  flaw in it at this time.  Because you are a Canadian citizen our files
  show Canada as your country.  This ... triggers the word Canada to
  appear in your address.  I am assured this will be corrected
  shortly. ...

For the record, this illustrates

(1) a design flaw in which a hidden assumption comes to light with an
exceptional case;

(2) bad quality assurance;

(3) the paucity in this database of Canadians who have moved to the USA.

M. E. Kabay, PhD, CISSP / Director of Education, ICSA, Inc.

Security vulnerability in Netscape

Tue, 25 May 1999 16:41:37 +0100 (GMT)
Netscape has a security vulnerability related to Javascript in
a <TITLE> of a bookmarked page, which is executed with the
privileges of the user when the bookmark file is next processed.

See <URL:> for more info.

Emperor Hirohito's death causes SW problems (Re: Y1.9K, R-20.41)

Stuart Woodward <>
Tue, 25 May 1999 16:15:53 +0900
I once worked on a software product for which an update was required to
support the new Imperial Era name ("Heisei") after death the previous
Emperor (a.k.a "Showa"). At the time I asked why the developers hadn't just
put the Imperial names and dates into a ini file which could be edited after
the death of the Emperor who was frankly getting on when the software was

The reply was that it had been thought of but by building this feature into
the product it could have caused offense by publicly anticipating the death
of Emperor.

Anyway, when he finally passed away, people continued to use the old
Imperial era year for some time in conjunction with the new until it was
supported by software and printed on forms etc. In the month after the new
era name was announced there were enormous sales of rubber stamps with the
characters for the new era name.

And guess what, I bet in 99% of Japanese software applications the era name
and start/end dates is still hard coded into the logic of the program as it
is just a convenient format for display and never a basis for calculation
which is done using the western date.

Re: JAVA language definition (, RISKS-20.41)

Jim Thompson <>
Mon, 24 May 1999 16:49:32 GMT
<> writes:

> Roy Wright and Daniel Graifer have pointed out that MS Visual J++
> sometimes uses a single return carriage to end a line, breaking some
> compilers.

Actually, Daniel Graifer's original report concerned the Visual C/C++ suite,
not J++.  The problem reported was that the Microsoft Visual editor would
display a single unix-style linefeed character <LF> as end-of-line, but that
the integrated compiler was not treating the <LF> character as end-of-line.
Thus, the compiled code did not match what the editor displayed, or what the
programmer expected.

This is not a failure to obey a standard; it is a failure of two related
applications, the editor and the compiler, to treat the *same* input in a
the *same* manner.  It is all the more unfortunate because the two
applications are "integrated", and should be consistent at least with each
other.  (They can't be consistent with the standard, because C++-style "//"
comments in C code are nonstandard.)

Jim Thompson <>

Re: JAVA Language Definition (RISKS-20.41)

Mon, 24 May 1999 09:50:22 -0400
How quickly we forget!

Twenty years ago it was PC/DOS vs mainframe and UNIX operating systems
grumbling about this same issue.  We still add the CRLF when converting from
EBCDIC to ASCII as we pull data down from a mainframe to out PC network.
Software companies DO create problems willfully for whatever purpose ... and
sometimes they get double benefit for their efforts.

Microsoft "fixes" the MS Office macro virus vulnerability

"Walker, Paul (India)" <>
Tue, 25 May 1999 17:50:11 +0530
As a service to RISKS readers who have to deal with the problem of
vulnerabilities in the MS Office software suite exploited by Macro Viruses,
I direct you to...

<quoted without permission>

  The download file, O2ksec.exe, contains the Microsoft Office 2000 Macro
  Security white paper. This white paper is a Word document that can be
  opened by either Word 97 or Word 2000. The Microsoft Office 2000 Macro
  Security white paper discusses how you can prevent the introduction of macro
  viruses into your computer using Office 2000.

  For example, Office 2000 introduces digital signatures to help users
  distinguish legitimate code from undesirable code, such as viruses. If you
  open an Office document and see a macro security warning with digital
  signature information, you can feel reasonably confident that the person
  (or corporation) who signed the macros wrote them. You can choose to trust
  all macros signed by this person by checking the Trust all macros from
  this source checkbox. From then on, when you open a document that contains
  macros signed by this trusted source Office enables the macros without
  showing a security warning for the document.

  If you use the Office 2000 digital signature features as advised in this
  white paper, you will not see annoying security warnings for any of the
  macro solutions that you write or use. You will only see a security warning
  when it is justified; that is, when you open a document with unexpected
  macros or viruses.

Before you go rushing off to get this Word document, I would like to bring
up the following points:

1/ the document comes as a self extracting and installing executable

(165 KB executable to install a 177 KB document into your "My Documents"
directory... how thoughtful!).

We all know how no one could ever hack the MS Web site and replace the
installation program with a Trojan to do additional tricks,

The document does not contain any macros, fortunately.  At least someone was
thinking a little ahead.

2/ the improved protection only comes if you upgrade to the next greatest
and latest software

I don't know about you, but if I was a large corporation with a macro virus
problem, I would resent having to do yet another upgrade just to get
protection that should have been in the software in the first place.

3/ the process of signing and certification relies on trust.

I trust that when you sign your macros that you cannot in any possible way
loose control of your private key.  You private key will be stored on your
computer, which we all know that on a Windows based computer, is completely
secure... well, let's not step off that bridge, shall we?

Fortunately, the document warns "Certificate owners should guard their
private keys carefully. Their reputations are on the line."

or shall we say that "their reputations are on-line"

With that warning, we all know that no one will overlook their security.

4/ "A Certificate Authority can issue you a digital certificate for code
signing for a fee. "

This basically means that we have to pay money to some anonymous "trusted"
authority to get our digital certificates...  this starts to go into the
realm of privacy.  We all know that this is completely safe and that the
rumours of back doors built into the encryption systems for international
versions of US software is completely false...
( , a must read if you are
into security and privacy issues)

There's many more issues that can be delved into with MS's current approach
to reduce (I cannot say "eliminate" because patching up a system that has a
bad security model in the first place will never solve the problem) the
problem with macro viruses.

If this system is "used properly", I believe that it will help reduce some
of the problems with macro viruses, but I don't believe that it will work
for long.  Some bright spark will find yet another hole to take advantage of
and the system won't protect you.

The other flaw in this system is that there is an assumption that users will
be educated enough to understand what all this means, certificates, trust,
signing...yada yada yada.  Not to knock the average user, but this will be a
very very large vulnerability.

The real solution is to disable macros in MS Office software permanently
with no way to turn it back on.  You can actually do it in office 2000, as
long as you are running Windows 2000 or NT4SP4 or greater.

(Do I hear another upgrade cycle spinning in here?)

Don't get me wrong, at the end of the day I am happy to use MS software in
spite of the problems.  I understand that the software is not secure.  I
keep my AV software updated.  I learn about where a document comes from or I
never enable the macros.  If I keep the limitations in mind, I have no
surprises or disappointments.

In fact, the last successful virus attack I have ever suffered was back in
'92 when I received an infected floppy disk from someone I trusted to know
better.  He got me twice!  Whoops...

Maybe I'm too paranoid..., yeah that's it.

Paul Walker, senior consultant, james martin + co
paul.walker AT

Embedded NT... in case you don't have enough to worry about already

"Gregor Ronald" <>
Mon, 24 May 1999 20:25:00 +1200
Here's a harmless one, but it still shows that things don't always go right;

New Zealand's new national Museum, Te Papa, in Wellington, is a "modern"
museum - highly interactive. I arrived as the doors opened, walked up to a
touch-screen information kiosk, and it said "At least one device or service
failed...... check the Event Log." Ah, I thought, this is the NT we all know
so well! A touch on OK and it booted, so the load failure was something

Now, if it had been a plane, or a ship, or a high-speed elevator, or.....

Gregor Ronald, Christchurch, New Zealand
Home:  Work:

REVIEW: "Microsoft Windows NT 4.0 Security, Audit, and Control"

Rob Slade <>
Tue, 25 May 1999 10:10:25 -0800

"Microsoft Windows NT 4.0 Security, Audit, and Control", James G.
Jumes et al, 1999, 1-57231-818-X, U$49.99/C$71.99/UK#45.99
%A   James G. Jumes
%A   Neil F. Cooper
%A   Paula Chamoun
%A   Todd M. Feinman
%C   1 Microsoft Way, Redmond, WA   98052-6399
%D   1999
%G   1-57231-818-X
%I   Microsoft Press
%O   U$49.99/C$71.99/UK#45.99 800-6777377 fax: 206-936-7329
%P   318 p.
%S   Technical Reference
%T   "Microsoft Windows NT 4.0 Security, Audit, and Control"

The primary audience described in the introduction seems to be security
professionals.  However, system administrators, technology managers, and
CIOs are mentioned as well.  The attempt at breadth of coverage usually does
not bode well in works like these.

Chapter one discusses an information security model based upon the business
(and other) objectives of the institution in question.  While valid as far
as it goes, and even possibly helpful when formulating security policy, this
by no means provides a structure from which to view either security policy
or procedures, let alone implement a complex set of controls.  The widget
company, beloved of management writers, is described in chapter two.  For
the purposes of assessing security in real world working environments, this
particular widget company seems to be astoundingly simple and homogeneous.

Chapter three starts out talking reasonably about security policy, starts to
get flaky in risk assessment (I would definitely worry about a .45 chance of
an earthquake), and tails off into trivia.  Monitoring, in chapter four,
looks first at system performance and diagnostics, and then gets into event
logging without really going into the concepts.  Many areas of physical
security are left uncovered in chapter five.  Chapter six discusses domains,
trust relationships, and remote access permissions.  Dialogue boxes for user
accounts and groups are listed in chapter seven.  There is some mention of
the commonly "received wisdom" in regard to these topics, as there is in
chapter eight regarding account policies, but nothing very significant.
File system, share, and other resource control is covered in chapter nine.
Chapter ten is a bit of a grab bag without much focus.  The registry is
reviewed in chapter eleven.  Chapter twelve looks briefly at power supplies
and backups.  Although it talks about auditing, chapter thirteen is more of
a checklist of security features to think about.  Appendix A is a bit better
in this regard: it lists recommended settings across a number of functions
for six different types of systems.

There is some discussion of options as the various functions are addressed,
so, in a sense, this is a start towards full coverage of NT security.  It
has a long way to go, though.  In addition, the deliberation comes at the
cost of a loss of some detail in terms of security implementation.

copyright Robert M. Slade, 1999   BKWNTSAC.RVW   990409    or

Please report problems with the web pages to the maintainer