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 95

Friday 11 September 1998

Contents

o Russian rocket blows 12 Globalstar satellites
PGN
o Starr Lite, Starr Bite, First Starr, We Scene Tonight
PGN
o San Francisco Muni removes streetcars to increase service
PGN
o Another Y2K bug revealed
Martin Minow
o It's good to have a cable modem when the phone system goes down
Fred Cohen
o Re: De-Rail Canada: A risk of Train-ing ignorance?
Rob Slade
o Re: "Windows NT Security", Charles B. Rutstein
Bob Frankston
o Info on RISKS (comp.risks)

Russian rocket blows 12 Globalstar satellites

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Fri, 11 Sep 98 9:43:47 PDT
Globalstar (42% owned by Loral Space and Communications) used a Russian
Yuzhnoye rocket for the launch of 12 Globalstar satellites intended to be
part of a world-wide wireless phone network.  Two separate computer faults
4.5 minutes after launch reportedly resulted in the complete loss of the
rocket and the satellites.  [Source: Dan Fost, *San Francisco Chronicle*, 11
Sept 1998, A1]

Missing bounds check?  This one certainly had leaps and bounds.
Off-by-one error?  Hardware?  I hope we can get some details.

All your eggs in one basket?  Not really.  Globalstar is shooting for
52 low-orbit satellites.

Cheaper by the dozen?  This one cost $270M for the satellites ($190M
expected to be covered by insurance!), and about $100M for the rocket.

  [This sounded like a Loral and Hardy launch when I heard
  a radio announcer mispronounce the company name as "Laurel".]


Starr Lite, Starr Bite, First Starr, We Scene Tonight

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Fri, 11 Sep 98 11:44:12 PDT {[corrected} time stamp\]
The 145-page executive summary of the Independent Counsel's report is now
on-line at various sites (including house.gov, cnn.com, time.com, msnbc.com,
nytimes.com, etc.).  Many media wags are telling a tale that massive
attempts at Web access will dog the performance of the Internet and
participating various servers, with the possibility that significant parts
of the Internet could crash.  Don't hold your breath while attempting access.

  [This expectation is of course quite consistent with all the evidence that
  the most-searched-for string on the Internet is "sex".  For example, a
  very modest item in RISKS-19.11 alluded to what an MS Word spelling
  checker did with the strings "zzzz" and "ZZZZ" -- without telling, the
  item pointed to a file (http://www.csl.sri.com/~risko/zzzz.html) that has
  repeatedly been found by subsequent web searches -- although undoubtedly
  to the disappointment of prurient searchers who are not RISKS readers.]

    [A note by Tom Abate in the *San Francisco Chronicle*, 10 Sep 1998, B1,
    notes that Mark Mooradian (who works with digital music for Jupiter
    Communications in New York) surveyed top search engines and rather
    startlingly claims that the *second-most-searched-for* string is "MP3",
    the International Standards Organization open standard that compresses
    three-minute songs into 3Mbytes instead of 45Mbytes; the fact that MP3
    has no anti-piracy protection is seriously worrying the music
    publishers, who obviously have alternative proposals.  As a complete
    aside not to be pursued in future issues of RISKS, I wonder how many
    folks are interested in *both* sex and pirated (or pirating) music!]


San Francisco Muni removes streetcars to increase service

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Thu, 10 Sep 1998 07:47:220 -0700
The San Francisco Muni folks have installed a $70M Alcatel Transport
Automation US computerized control system in an attempt to improve service
often plagued by mishaps.  This turns out to work well for the newer Breda
streetcars, which can communicate with one another.  Unfortunately,
communications were blocked when the 17-year-old Boeing-Vertol cars were
simultaneously in use, which was particularly annoying when the old cars got
stuck in the downtown tunnel.  The short-term fix was to remove 20 Boeing
cars from service (out of a fleet of 136), until they can be converted.
This fix reduced the computer-related problems, but also seriously reduced
capacity.  Operating in passenger overload is also a problem, because if a
Breda car door fails to close after several attempts because of passengers
blocking the door, the computer system interprets this as a mechanical
failure, and shuts down the entire Metro!

"Alcatel contends that its system is working fine and that Muni's problems
are with its equipment and personnel.  Muni is fining Alcatel $25,000 a day
until the software system works properly and allows Muni to increase the
number of trains it operates under Market Street.  The city and Alcatel are
already involved in a legal fight."  [Source: Edward Epstein, Muni's
solution -- take 20 cars out of service, *San Francisco Chronicle*, 4 Sep
1998, A1; PGN Stark Abstracting; Terry Clifton <top_cat@ns.net> augmented my
morning newspaper reading by sending me the article on-line.]

In a subsequent event, a driver stepped out of his streetcar to get a drink
of water, apparently forgetting that it was on automatic control; the good
news is that the automatic system worked just fine and the streetcar went
several stops unattended without incident.  (Ken Garcia in the 10 Sep
*Chron* noted that some people were upset by the driverless run, but
suggested that the real reason might have been that "there was no Muni
person around to yell at.")


Another Y2K bug revealed

Martin Minow <minow@apple.com>
Fri, 4 Sep 1998 13:22:49 -0700
One of my colleagues got a letter from <Enormous Company> (name changed to
protect the guilty) confirming an order he'd placed.  The letter was dated
August 3, 2098.

It turns out that a friend of mine is Y2K manager for that company, When I
mentioned it, he asked for a copy of the letter and tracked the problem down
(and was very pro-active in communicating what had happened).

As you might expect, new software went online in late July with Y2K
windowing turned on, and there was a minor bug in one of the modules. The
bug was fixed ten days later but, before the fix went into production, "a
half-million" confirmation letters were sent out with wrong date.

Fewer than a dozen people noticed and called <Enormous Company>, and it
appears that my colleague and I were the only people to actually recognize
this as a Y2K bug.

Moral for Risks? Get your fixes in early, expect problems, don't expect too
much help from the public.

Martin Minow, minow@pobox.com


It's good to have a cable modem when the phone system goes down

Fred Cohen <fc@all.net>
Tue, 1 Sep 1998 20:53:04 -0700 (PDT)
In the 925 area code - just today officially severed from the 510 area code
- you might be well advised to have a cable modem to get to the Internet.
My cell phone works (which has been 925 area code only for some time) but
every number in the 925 area code that was also in the 510 area code till
today seems to be out of service. IF we can't handle September 1, 1998, how
we we ever be able to handle 2000/01/01?

Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171
Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225


Re: De-Rail Canada: A risk of Train-ing ignorance? (Martin, R-19.94)

"Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
Fri, 4 Sep 1998 23:25:09 -0800
> ... but inadequate knowledge and training, coupled with miscommunication ...

The inadequate training part seems to be rather an understatement.  Only one
of the news stories I've heard has mentioned, and that very briefly, that
none of the train crew, and none of the maintenance crew in the West, had
any training on the warning system.  The nearest trained staff were over
3000 km distant in Ontario.

rslade@vcn.bc.ca     rslade@sprint.ca     slade@freenet.victoria.bc.ca


Re: "Windows NT Security", Charles B. Rutstein (Slade, RISKS-19.89)

<Bob_Frankston@frankston.com>
Thu, 6 Aug 1998 20:12 -0400
The discussion about the lack of NT security books seems to miss the larger
issue. Much of the thinking of computer security seems to hark back to the good
old days when we knew how to build secure systems. And to simple systems such
as Unix that provide simple security models for simple problems.

I too am nostalgic for the old days of Multics when security was defined in
terms of usability. The requirement was the users be able to trust the
system.  This was less an issue of military security than being able to
specify what access was to be given and to whom. The system was honed with
just Read/Execute/Write (and Append, but that's already a messy one) on
files (and directories). The Access list could explicitly list users or
projects (administrative groupings of users). If the user didn't know about
the security system, by default, there weren't any further exposures.

Unix had a different design point. The system was assumed to be like a
friendly work group with papers left on desks for easy access. Unix default
was to allow the world to read all of your files. Not safe for the naive but
unlike Multics the assumption was that you really didn't want to keep
anything confidential on your computer. (I know I'll be flamed for this but
defaulting to read means that only fools would trust the system
security. Alas, the default is to be a fool.) The initial access system with
groups made any attempt to really control access problematic. And then SU
was thrown in to get around all of this.  Perhaps some of this has been
address but to think of Unix as the model for security seems silly.

Then there were PC's and other small systems that simply lacked any notions
of access control. That was fine since they were never ever going to be on a
network.

So now we have gripes about NT. In fact, NT has a very sophisticated
security model with the ability to specify access control for all sorts of
objects. And it has been C2 certified (at least, in a vacuum, networks tend
to be problematic in the world of security). The problem with NT is that
there is no effective UI for security. More to the point, thanks to the
sophistication (AKA complexity), it is difficult to understand what is
really going on in terms of security. Especially with mechanisms such a path
access (security on shares) mixed in.

Of course, these systems have common problems like security being specified
in terms of local certification authorities (i.e., the local system
directory or the NT domain).

But the REAL problem is that de jure (or military) model of security has
little to do with the real world:

=> The attributes associated with files have little to do with the access
appropriate for programs (agents) acting on behalf of users. The result is
that programs get wide access (in Unix via SU, in NT there might be a finer
grain) and then must make sure they don't "abuse" this authority due to
bugs.

=> Mapping identity into a login ID is naive since users might have
different authority based on roles.

But the most important issue goes back to the Multics' principle that all is
moot if the user doesn't understand the system and is not comfortable with
this understanding.  And the defaults must be safe. The current systems
require vigilance. Perhaps that's OK in a world of de jure where the user is
blamed for mistakes. But in the real world this is called an insensitive
bureaucracy for good reasons.

If this weren't bad enough wrapping firewalls and other bad ideas around all
this and call it a solution just adds to the complexity.

If I need to read a manual to be secure, I don't have security.

Furthermore, systems security is a minor part of the problem. The real issue
is security of the applications. What authority am I giving to what user
with what intent under what circumstance. How do the operating system
mechanisms serve these needs?

In the old days of time-sharing systems where we just wanted to protect
files online things were simpler. The world is more interesting now and so
is the question of what we mean by security.

Please report problems with the web pages to the maintainer

Top