The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 19 Issue 76

Monday 25 May 1998


o Navy stops teaching celestial navigation
George Mannes
o Re: Navy turns to off-the-shelf PCs to power ships
Jeff Jonas
Paul Wright
Marc Binderberger
Greg Lindahl
o Navigation tech and the Navy
Mike Albaugh
o Medical effects of the Galaxy IV malfunction
Ron Adams
o Satellites and pagers
Mickey McInnis
o GPS correction
Dave Weingart
o GPS jamming/spoofing
Paul Wallich
o Failure modes when the power fails
Nicholas C. Weaver
o Computer-based election problems?
Debora Weber-Wulff
o Re: Encrypting e-mail -- or not?
Dorothy Denning on Michael Stutz
o ZDNet Grief
Thomas J. Gilg
o Info on RISKS (comp.risks)

Navy stops teaching celestial navigation

George Mannes <>
Thu, 21 May 1998 15:26:16 -0400
> ANNAPOLIS, Md. (AP) -- The computer has sunk the ancient art of celestial
> navigation at the Naval Academy.  In the new academic year, midshipmen
> will no longer have to learn the often tedious task of using a
> wedge-shaped sextant to look at the stars and plot a ship's course.
> Instead, the academy is adding a few extra lessons on how to navigate by
> computer.  Naval officials said using a sextant, which is accurate to a
> three-mile radius, is obsolete.  A satellite-linked computer can pinpoint
> a ship within 60 feet. [...]

George Mannes, Two Rector Street, 14th Floor, New York, NY 10006

  [Also noted by George Dinwiddie <>, (David W. Crawford) (who remarked on the timeliness of
    Peter Ladkin's summary of GPS vs sextant!), and (Paul S. Miner).]

      [I suppose SEXtants have been eliminated in response to
      the Navy's efforts to avoid repetitions of Tailhook.  Or
      perhaps references to these devices were being censored
      by filtering programs and removed from training manuals.  PGN]

Re: Navy turns to off-the-shelf PCs to power ships (RISKS-19.75)

Jeff Jonas <>
Thu, 21 May 1998 15:25:03 -0400 (EDT)
I can't remember the acronyms, but for many years now, US military
acquisition has been adjusting to using standard commercial products in
places where military spec was not warranted.  I'd like to believe that it's
due to commercial products being ISO9001 compliant and highly reliable, thus
meeting many needs.  (ex: ASUS motherboard monitor fan rotation, power
supply voltages and all).

But I agree that off the shelf parts just don't have the ACCOUNTABILITY and
MAINTAINABILITY that's required by military contracts, so I doubt any
integrator/contractor will risk using too many leading edge parts.  I'd like
to believe there are some checks-and-balances to the procurement system and
at some point, someone's head risks being on the chopping block, so
untrustworthy parts get blocked (lest they lose the contract and all future

As to software, I'm unsure off the shelf is allowed since it does not meet
security levels; needs to support all the proprietary military interfaces &
protocols and such.

On the bright side, SUN makes militarized systems (a friend noted Suns in

Jeffrey Jonas jeffj@panix(dot)com

Navy turns to off-the-shelf PCs to power ships (Educom)

Paul Wright <>
Thu, 21 May 1998 21:35:08 -0400
I work in the weapons safety area for the U.S. Navy.  One of my great fears
is having a weapon system come in running under Windows (any version).  So
far, I haven't seen that.  Not that there aren't systems running under
Windows, but (so far) not the systems directly pointing/firing weapons.  We
did have one system proposed to run under Windows (3.0 at the time, I think)
that would have popped up a dialog box at the Tactical Action Officer's
station saying "Fire Now!", but it never made it beyond engineering
development.  Actually, I figure the TAO would have looked down for advice
and found "Memory Error at Krnl.exe!" but that is another issue.

Software safety is one of our big concerns.  We know how to analyze gears,
springs and levers.  20 programs on 5 different kinds of processors under 10
different languages are a harder problem.  The one saving grace with Windows
is that we can ask the program manager how many times he has booted his
computer today.  Luckily, few of them have Macs.

Off the shelf PCs are going into service.  They are spinning up torpedos
and tracking ships and correlating radar tracks.  Acquisition reform can put
Packard Bell in control of lots of things.  But not yet Navy weapons.

Re: Navy turns to off-the-shelf PCs to power ships (RISKS-19.75)

Thu, 21 May 1998 20:21:11 +0000 (GMT)
Chiaki Ishikawa was wondering, if ...

> I am not quite sure what the phrase in the Educom headline "off the shelf
> PC", but I certainly wish that the Navy is not trusting weapon control or
> cruise control to Windows 95.

>From the "Secure Windows NT Installation and Configuration Guide",
produced by the Naval Information Systems Security Office, PMW 161:

"The Microsoft Windows NT Server 4.0 is the standard fleet NOS."

"In response to fleet demand, the Navy has issued formal record message
directing the migration to Microsoft's Windows NT 4.0 Server and
Workstation OS no later than December 1999."

Regards, Marc

P.S.: I don't remember what the original location was. You may find my
copy at

Marc Binderberger, 97076 Wuerzburg, Germany

Re: Navy turns to off-the-shelf PCs to power ships (Educom)

Greg Lindahl <>
Thu, 21 May 1998 16:32:06 -0400
> The U.S. Navy, facing pressure from Congress to cut spending, is
> maintaining its cutting edge by replacing expensive custom-built systems
> with off-the-shelf products.

This is less alarming than it sounds. The fact is that the fraction of all
semiconductors purchased by the US military has gone from over 50% to a
fraction of 1%, so the military can no longer expect its market clout to
cause vendors to design special hardware for it. This has resulted in a
migration from highly custom boards to ordinary industrial-strength
single-board computers with commodity CPUs, running commercial real-time
operating systems where appropriate.  Nope, no Windows95 controlling missile

You should be more alarmed at the prospect of all the military systems in
the field for which spare parts simply cannot be purchased -- how many years
until no 5 volt chips are produced? Will reliance on computerized control
result in the early demise of many weapons systems, at great cost (and risk)
to the taxpayer?

-- greg

Navigation tech and the Navy (Re: Ladkin, Frankness, RISKS-19.75)

Mike Albaugh <>
22 May 1998 17:49:25 GMT
I just can't wait for the day when one of the class of '00 finds herself in
mid-Pacific with the blue-screen-o-death on the Wintel98 box that was
supposed to display the GPS output :-)

Later, someone quoted Henry Spencer that:

: Having a supposedly-reliable navigation aid that is lying to you is
: much worse than having to get by without it.

Which is related to why I miss the old VaxVMS debugger's habit of admitting
that it didn't really know what the current value of a variable was. The
"modern" spiffy IDE's I occasionally have to use will blandly lie through
their little cyber-teeth and claim preposterous results at equivalent
times. Of course, the only real threat to my life from such shenanigans has
to do with blood-pressure :-)


Medical effects of the Galaxy IV malfunction

Ron Adams <>
Thu, 21 May 98 14:07:35 -0500
I heard on NPR yet another manifestation of the Galaxy IV malfunction: the
inability of some pharmacies to verify insurance coverage during
prescription refill requests.  Elderly persons were told to pay cash or use
a credit card to cover the full retail price, not just a co-payment.  When
some people could not do so, some pharmacies apparently dispensed one or two
day supplies (probably suspending existing rules...quite in contrast to that
Chicago hospital emergency room....)

Ron Adams, Principal - Logistics, The SABRE Group, P.O. Box 619615 M/S 4311,
DFW Airport, TX 75261

Satellites and pagers

Mickey McInnis <>
Thu, 21 May 1998 14:09:25 -0500 (CDT)
I think the recent satellite failure vs. paging failures merits further
study and, perhaps, even regulatory action.

Consider this scenario.

1) You buy paging service from a company with a local presence, i.e., they
have a local office, people working here, etc.

2) You call a local phone number to enter a page.

3) A local radio transmits the signal to your pager.

Those unfamiliar with the process would tend to assume that the process
of sending a page works locally, but in fact, it gets transmitted
through one or more satellite links and through facilities in multiple
ground stations.  (At least this is the way many paging systems work.)

Hospitals, doctors, and other emergency personnel (and those who depend on
them) are dependent on paging systems.  Many businesses are dependent on
paging systems.  Many of these customers could be well served if there was a
standalone "local" part of the system that works without communicating with
the home office.  Should these customers have been more informed of the
"weak" links in the paging system?

Should the paging companies have provided an autonomous local system or a
local backup network?  I would say it's obvious that such a system could be
provided, and even a ground-based backup for the satellite link could be
provided, but it's a matter of cost.  i.e. the system could be more robust,
but it will cost money.

I think that the road ahead is paved with lawyers for the paging companies.

If your business or some service you need depends on pagers, you had better
consider what kind of backups you have.  You might also want to have a talk
with your paging company to see what kind of backups and failure points they
have.  Perhaps if enough customers press them on the issue, they'll work on
their backups.  Of course, if you asked them last week about backup systems,
they would have probably assured you that they have redundancy and backup

Actually this points out another problem.  How do you really find out how
good the contingency plans are for that service you buy from a multi-billion
dollar multinational company?  How do you know that the new CFO for the
company won't farm out some vital component of the system to some location
in a foreign company halfway around the world with shaky telecommunications
links, potential political unrest, or some area affected by natural

Perhaps the only safe bet is to have a penalty clause for outages that is so
severe that you make more money if the system is down than if it's up.

You should also consider your side of the paging (or other
telecommunications) system.  Did you consolidate something in some remote
location to save money?  What happens with the phone lines or that site
breaks down?

However, as one comedian pointed out last night on cable, perhaps there is a
bright side and drug dealing has decreased the past day or two.

Mickey McInnis -

GPS correction (Re: RISKS-19.75)

Dave Weingart <>
Thu, 21 May 1998 14:51:39 -0400
Actually, I believe that the satellite is owned by some division of General
Electric, but is *operated* by PanAmSat.  (My pager, BTW, was one of those

Obvious Risk: I wonder if the embedded systems on the communications
satellites that we all depend on now are Y2K-compliant?

Dave Weingart, AccuStaff Inc.  1-516-682-1470

  [As you recall, there is apparently still a problem that some receivers
  will fail at midnight between 21 and 22 August 1999, resetting to 6 Aug
  1980.  See RISKS-18.24.]

GPS jamming/spoofing

Paul Wallich <>
Wed, 20 May 1998 11:48:57 -0400
I think some of the confusion I've seen in recent comments about GPS jamming
comes from a failure to distinguish pure jamming (making GPS unavailable)
from GPS spoofing (transmitting signals that cause a GPS receiver to report
an erroneous position). Spoofing, as far as I understand it, is in principle
a malicious form of differential GPS (in which a ground-based transmitter of
fixed, very-well-known position emits signals based on the difference
between its known position and its GPS-derived position.  I've seen such
transmitters referred to as "pseudolites" because they apparently appear to
GPS receivers as members of the GPS satellite constellation.) Someone who
knows this stuff cold might give a much better explanation.

In the meantime, the US Naval Academy has announced that middies will no
longer have to learn to navigate by sextant, evidencing a touching faith in
the invulnerability of GPS transmitters and receivers under combat and
disaster conditions...

Paul Wallich <>

Failure modes when the power fails

"Nicholas C. Weaver" <nweaver@hiss.CS.Berkeley.EDU>
Fri, 22 May 1998 10:49:20 -0700 (PDT)
On Tuesday, May 19, at approximately 11:50 pm, the UC Berkeley campus lost
power for a few hours.  Apparently what happened is that there were some bad
insulators in the main campus substation which needed to be replaced
urgently.  The campus attempted to switch over to the backup power source (a
generator facility which can provide roughly 80% of the power) but that
failed, causing a blackout until the generator could be repaired.

In the CS department we also learned something of how things fail.  Being a
rather large department, cardkeys are used to control access to many floors
and rooms.  Some cardkey locks have their own power supply, others don't.
Those with power are unable to reach the controlling computer, and default
to "unlock with any cardkey", while those without power default to locked.
It is interesting that the machine rooms, wiring closets, etc, all had power
and therefore were all unlocked, while many of the stairway doors (to get to
the upper floors) were locked.  This suggests that we need to put the
controlling computer on a UPS and check the backup power supplies for all

Another interesting failure damaged our file servers.  Our two big Auspex
servers have short term (<30 minute) UPS power supplies, which actually
worked this time.  (Previously, we have had the UPSs fail).  However, there
were not enough plugs in the UPSs, and the consoles for the machines were
not plugged in to the UPS power supplies.  The admins failed to find a
9<->25 pin serial adapter in time to hook up a notebook before the UPSs ran
out of power.  Fortunately we have very good system administrators, and with
the exception of a blown power supply which powers some of the disks,
service was restored by the next day.

Computer-based election problems?

Debora Weber-Wulff <>
Tue, 19 May 1998 16:35:30 +0200
(written May 11, but our news server refused moderated groups until today...)

The general election in Germany is not until September, but a fight is going
on in Berlin about the new election software. It was purchased from a town
in the west of Germany, Hamm. The software was developed by programmers at
city hall. It seems that the software is cool and runs under Windows 95 (did
I hear someone shuddering out there?), but that there are problems
interfacing to the "ancient" 16-bit software currently in use in Berlin for
tallying the results from the boroughs. The "Tagespiegel" ran a large
headline about the possibility of no election data in Berlin because of the
16-bit/32-bit incompatibility. A few days later we had the angry replies
from Hamm, if Berlin would just get their act together and upgrade their
Windows 3.1 machines everything would be just fine. The ward leaders have
now replied that the software is probably okay, they just have a lot of
training to do.

I see more than Windows problems here, Hamm has 190,000 inhabitants, Berlin
has about 3.4 million. Could be a slight scale-up problem here, stay

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

Re: Encrypting e-mail -- or not?

Dorothy Denning <>
Mon, 18 May 1998 10:33:42 -0400
>From the article by Michael Stutz, "Security Bugaboo in MS Outlook?"
in Wired News, posted by James Glave:

  The bug arises when a user creates an encrypted message and then tries
  to cancel it -- the message is not cancelled, but is sent, sans

Isn't there another risk here, namely, that a message thought to be
canceled was not?  The consequences of that could be as bad as third
party interception.  For example, suppose an employee is angry at their
boss and composes an inflammatory message with a notice of resignation.
Then, after blowing off some steam, decides to cancel the message.

Dorothy Denning

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

>Date: Tue, 12 May 1998 08:52:03 -0700
>From: James Glave <>
>Subject: Encrypting e-mail -- or not
>The risk here is that an e-mail that was intended to be sent encrypted is
>instead sent as cleartext, thanks to a completely avoidable bug in the
>interface.  Obviously the interface testers dropped the ball here in a big
>Security Bugaboo in MS Outlook?
>by Michael Stutz, 12 May 1998
>The user interface of Microsoft's Outlook 98 e-mail application is the cause
>of a new security-related bug, where users could be fooled into thinking
>that an unencrypted communication is actually encrypted -- thus sending
>potentially sensitive information in plaintext over the wires.  "The problem
>manifests itself two ways," said Scott Gode, Microsoft product manager for
>Outlook. "One is that the message is not digitally signed, and the second is
>that the message is not encrypted."  VeriSign Inc. makes the digital
>certificates that are used with the S/MIME encryption in Outlook 98; these
>certificates are used to encrypt and create digital signatures for messages
>sent with the program. The bug arises when a user creates an encrypted
>message and then tries to cancel it -- the message is not cancelled, but is
>sent, sans encryption.  When a recipient replies to the message, thinking
>that it was an encrypted communication, the reply e-mail is also sent with no
>encryption.  "All further messages sent in reply from either party are sent
>as unencrypted plaintext messages. And there's no notification to anybody
>along the way at any time," said Russ Cooper, consultant and moderator of
>the NT Bugtraq and NT Security mailing lists. Cooper discovered the bug
>while testing the S/MIME crypto features of Outlook 98.  The flaw is not in
>VeriSign's crypto implementation, rather it's in Outlook 98's user
>"This is mainly a user interface issue," said Gode.  "The architecture and
>integrity of what we're doing is not flawed -- it's just the way that the
>software responds to the dialog box."  "It looks to me that this is very
>specific to this implementation," said Glenn Langford, group manager for
>desktop applications at security and crypto software company Entrust
>Technologies.  "This kind of thing wouldn't happen in our scenario, because
>in an Entrust environment, what we're doing is not just issuing certificates
>-- we're doing the certificates, the key management, toolkits, and the e-mail
>plug-in implementation all at the same time," he said.  The weakness of the
>VeriSign situation, he said, is that it's up to the implementor of the e-mail
>package -- in this case, Microsoft -- to do the security properly, because
>there's no toolkit running on the client platform. So if there's a bug
>involving the e-mail package, even though the VeriSign application functions
>perfectly, there's a security hole.  Bruce Schneier, crypto expert and
>president of Counterpane Systems, is fascinated by the bug.  "It's yet
>another example of cryptography broken by bad user design," he said. "This
>works counter-intuitively."  "They've gotta fix it -- they can't wait for
>the next version, in my opinion," Cooper said.  Microsoft, however, is
>unable to reproduce the bug.  "We've been able to reproduce the problem of
>[a message] not being digitally signed," Gode said, "but have not been able
>to reproduce the problem of [a message] not being encrypted, which is
>obviously the more potentially damaging of the two."  Gode said that the
>company had been aware of the bug from other sources since late April, about
>a month after Outlook 98 was released. He said that the company has
>contacted Cooper -- who made his description of the bug public on Friday --
>with the hope of getting more data so that they could reproduce it.  As to
>what causes the second part of the bug, where the message is sent
>unencrypted, Gode said that any number of possibilities could be involved,
>including how Cooper configured his machine -- or an error on Microsoft's
>part.  "It could be a legitimate thing that we messed up on," he said. "I'm
>not ruling that out, but because we can't reproduce it and because we're not
>hearing this from other people, it's hard to say at this point."  How could
>such a simple bug have slipped through development testing?  "People don't
>notice, because code is complicated," said Schneier. "This is the big
>problem with the Net. Look at Netscape Navigator:
>It comes out, bugs are found, bugs are fixed; more bugs are found, more bugs
>are fixed -- you'd think it gets better, but then a newer version of
>Navigator is released, with 80 percent more source code, more lines of
>code," he said.  "There's absolutely no substitute for public scrutiny,"
>Schneier said. "But you only get scrutiny to the level of what's public."
>And so if any portion of the code is unavailable for scrutiny, the security
>risk is increased.  "Not just the security portion of a code can compromise
>security," Schneier said. "Just because the digital signature and key
>management [portions of the source code] are correct, doesn't mean that you
>can't write a user interface that breaks the security."  Not everyone thinks
>this bug is so catastrophic.  "It would be a bug of a different magnitude if
>the user who sent the original message had every reason to believe that it
>were sent encrypted," said Ted Julian, an analyst at Forrester Research.  As
>for when the bug will be fixed, Microsoft said it will play it by ear.  "If
>[the problem] is severe and if it's something that it turns out we're able
>to reproduce -- and we think it could cause problems to other users -- that
>might necessitate some sort of little patch that we could make available on
>the Web," said Gode. "If it remains just the digital signing problem, that
>would be something we'll probably just have people live with for now until
>an interim release -- if there is one -- or until the next version comes
>out."  Check on other Web coverage of this story with NewsBot
>James Glave, Senior Technology Writer
>Wired News  (415) 276-8430

ZDNet Grief

"Gilg, Thomas J." <>
Thu, 21 May 1998 11:10:46 -0700
Like Ken McGlothlen (see RISKS 19.74), I also received an "Announcing ZDNet
Mail" notice. It told me an account was already setup for me, and that all I
needed to do was visit their WEB site and enter my old ZDNet username and
password, which ZDNet unfortunately included (problem #1) as plain text in
their notice directly to me.

Problem #2 is that prior to this notice, I tried to unsubscribe from ZDNet,
but even though I only recall *one* point-of-subscription, I've had to visit
2 separate points-of-unsubscription (ZDNet "Software Express" and ZDNet
"ANCHORDESK") and am nowing trying to deal with a 3rd
point-of-unsubscription (ZDNet "Update").  In all fairness to ZDNet, they're
not the only ones with *one* point-of-subscription that results in
(unbeknownst to the subscriber) *multiple* points-of-unsubscription.

Problem #3 (stupid me) is that while preparing this report, I visited the
ZDNet Mail Web site, went out of my way NOT to enter the "Member" zone using
my old username and password, and instead entered the "non-Member" zone to
see want type of information they would want from me.  Arrggg, the
non-Member page still recognized me and instantly announced "xxxxx, thank
you for joining ZDNet .... Access your new ZDNet Mail account ...."  Zero
warning going in, and no final OK/Cancel option.

Problem #4, there is no apparent information on how to unsubscribe from
problem #3.

Problem #5, unlike e-mail based subs/unsubs, I have few transaction records
from all of the unfortunate web-based subs/unsubs and encounters.

ZDNet is like quick-sand - every move I make to get out, I sink farther in.

Thomas Gilg <>

Please report problems with the web pages to the maintainer