The RISKS Digest
Volume 21 Issue 1

Tuesday, 15th August 2000

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…

Contents

Russian nuclear sub trapped on bottom of Barents Sea
Keith A Rhodes
Risks of train doors: Sydney
Simon Carter
Admissions mixup leaves Northeastern University struggling
Daniel P. B. Smith
Not so smart weapons in Kosovo
Lord Wodehouse
Private phone records on Web
Kevin L. Poulsen
Barclays Internet-banking security-glitch following software upgrade
Pete Morgan-Lucas
Security hole in Netscape
NewsScan
The Pentagon worries that spies can see its computer screens
Gregory F. March
Online gambler goes to prison
NewsScan
County blew $38 million on canceled payroll system!
Joan Brewer
Delays in the new UK Air traffic control system
Ursula Martin
Microsoft vulnerabilities, publicity, and virus-based fixes
Bruce Schneier
REVIEW: "NT 4 Network Security", Strebe/Perkins/Moncur
Rob Slade
Info on RISKS (comp.risks)

Russian nuclear sub trapped on bottom of Barents Sea

<"Keith A Rhodes"<rhodesk.aimd@gao.gov>>
Mon, 14 Aug 2000 07:22:26 -0400

A Russian nuclear submarine malfunctioned while on exercises, and was
trapped on 13 Aug 2000 on the bottom with a crew of more than 100 aboard.
[There was not much hope for the crew.]

[*Izvestia* reported recently that, according to the most conservative
estimate, 507 submarine crew members have died during the 40-year history of
Russian nuclear submarines, not counting this one.]

  [Source: Article by Barry Renfrew, Associated Press, 14 Aug 2000; PGN-ed]
  [I think the most telling line in this report is that the Russian Navy is
  in a shambles with their vessels getting no regular maintenance.  Seems
  that in this case the tables have turned — usually everyone is
  complaining about not keeping up with their software maintenance, although
  I guess that if they did not maintain the vessel's mechanical systems,
  they did not maintain its computer systems.  Keith]


Risks of train doors: Sydney

<Simon Carter <smjc@svrc.uq.edu.au>>
Tue, 01 Aug 2000 13:57:36 +1000

This is the latest in a series of disasters and irritants on the Sydney
train system:

> As a commuter, Mr Dee almost became a victim of the system he supported
> when his leg became trapped in a train door as it left Meadowbank Station
> on Sunday afternoon.

http://www.smh.com.au/news/0008/01/text/national3.html

A colleague suggested:

> This one's almost worth sending to RISKS forum. Train doors have a long
> history of hazardous action (or inaction, as in this case).
>
> Off the top of my head:
>
> For a long time, Brussels metro had no automatic opening mechanism, so
> that anything trapped in a closing door stayed trapped. It sounds like
> Sydney used the same contractor.
>
> Calgary did install an opening mechanism, but the sensors failed when
> the rubber door seals hardened at -30C.
>
> More amusingly, a woman jumped onto the London U/G, except the doors
> shut on her handbag. "No worries, I'm getting off next stop, I'll get it
> back then." The doors opened on the other side of the carriage.
>
> There's a story somewhere about a computer-controlled train
> persistently stopping out of alignment with doors on the platform edge.
>
> 'Fraid I can't give a reference for any of these.
>
> David

[David Tombs <Tombs@svrc.uq.edu.au>]

I recall there were numerous problems with the Bay Area BART system when
it first went into service (mid '70's?).  All sorts of things including
doors opening while traveling between stations.

Simon Carter <smjc@svrc.uq.edu.au>

  [Lots of rail problems in the RISKS archives.  See
     http://www.csl.sri.com/neumann/illustrativerisks.html
  and click on Rail, Bus, and Other Public Transit in the index.  PGN]


Admissions mixup leaves Northeastern University struggling

<"Daniel P. B. Smith" <dpbsmith@bellatlantic.net>>
Thu, 10 Aug 2000 05:56:43 -0400

After problems with its new computer system, Northeastern University
unintentionally admitted 25 percent too many freshmen — 600 extra students
-- for this fall.  Earlier, the names of hundreds of potential applicants
had been lost when the system was first installed, which resulted in an
aggressive campaign to enroll the students who had been accepted.  [Source:
*The Boston Globe*, 10 Aug 2000; PGN-ed]

Daniel P. B. Smith, 35 Mountain Ave, Norwood, MA 02062
dpbsmith@bellatlantic.net  (Lifetime address: dpbsmith@mit.alum.edu)

  [Also noted by Dave Bank.  PGN]


Not so smart weapons in Kosovo

<Lord Wodehouse <w0400@bigfoot.com>>
Mon, 14 Aug 2000 13:23:02 +0100

Yet again there is any report on smart weapons, actually not being as smart
as portrayed by the military. It is so like the hype of the Patriot missile
(various issues of RISKS [and the illustrativerisks.html archive]). This
survey was carried out by Flight International and the BBC radio Today
programme.  http://news.bbc.co.uk/hi/english/uk/newsid_879000/879560.stm

The risks are again obvious. The computer game warfare style does not
deliver what it is meant to do so, but the military continues to pursue it,
because they can get more money that way.

The prospects for the NMDS (son of Star Wars) looks even more unrealistic in
this light. I strongly believe that we all need a good dose of reality in
relation to what technology and computers can do, and where other factors,
such as the weather limits the optimistic expectations.

Global Research Information Systems, Glaxo Wellcome, Stevenage SG1 2NY UK
 +44 1438 76 3222  w0400@ggr.co.uk  http://ds.dial.pipex.com/lordjohn/


Private phone records on Web

<"Kevin L. Poulsen" <klp@securityfocus.com>>
Mon, 14 Aug 2000 11:11:07 -0700 (PDT)

http://www.securityfocus.com/news/074

Verizon's twenty-eight million residential and business telephone
subscribers from Maine to Virginia had portions of their private telephone
records exposed on a company web site, SecurityFocus has learned.

The telephone giant, already struggling in a strike by union workers, was
scrambling Sunday night to shut down the offending web application: a
system designed to allow customers to file new repair reports, and track
existing reports, over the Internet. Because of a basic design flaw, users
could put in any phone number in Verizon's northeastern U.S. service area,
and, by viewing the source of the resulting page, see the owner's name and
address, as well as other information.

"We're going to have to go to a fix, obviously," said company spokesperson
Larry Plumb, who learned of the flaw through SecurityFocus's
inquiry. "We won't open up that application again until we have the
problem solved."

Kevin L. Poulsen, Editorial Director, SecurityFocus.com,  Washington D.C.
(202)232-5200


Barclays Internet-banking security-glitch following software upgrade

<Pete Morgan-Lucas <pjml@nsgmail.nerc-swindon.ac.uk>>
Tue, 1 Aug 2000 09:30:44 +0100 (BST)

Barclays Bank yesterday had a problem with their online banking service - at
least four customers found they could access details of other customers.
Barclays are claiming this to be an unforeseen side-effect of a software
upgrade over the weekend.

See http://news.bbc.co.uk/hi/english/business/newsid_860000/860104.stm
for more details.

//Pete Morgan-Lucas//  NERC_ITSS Network Security, NERC Swindon.

  [Also noted by AllyM at http://www.theregister.co.uk/content/1/12287.html
  and Andrew Brydon in a BBC item that mentioned 7 complaints.  PGN]


Security hole in Netscape

<"NewsScan" <newsscan@newsscan.com>>
Tue, 08 Aug 2000 07:32:18 -0700

Because of a security hole in the Netscape browser, about a thousand
computers have been infected in a way that would allow a network vandal to
see, run, and delete files on the victim's computer. Netscape is working
rapidly to solve the problem, but network security experts are suggesting
that, until the solution is found, Netscape users should disable the Java
programming languages in their browsers. [AP/*Los Angeles Times*, 6 Aug 2000,
http://www.latimes.com/business/cutting/20000808/t000074055.html;
NewsScan Daily, 8 August 2000]


The Pentagon worries that spies can see its computer screens

<"Gregory F. March" <march@gfm.net>>
Thu, 10 Aug 2000 08:59:11 -0400

There was a front page article in the *Wall Street Journal* (7 Aug 2000)
discussing the technology and risks of video-screen snooping by scanning the
EMF radiated by the monitor.

I'm not an engineer, but I can put two and two together.  I have a wireless
keyboard and mouse.  If someone could view my monitor remotely and then send
the appropriate commands to my Logitech mouse/keyboard, it could be a *huge*
potential risk for leaving my machine on and unattended.

Gregory F. March    -=-    http://www.gfm.net/~march    -=-    AIM:GfmNet


Online gambler goes to prison

<"NewsScan" <newsscan@newsscan.com>>
Fri, 11 Aug 2000 09:53:55 -0700

A co-owner of an online offshore gambling business based on the Caribbean
island of Antigua has been sentenced to 21 months in a U.S. prison for
violating this country's federal Wire Wager Act, which makes it illegal to
use telephone lines in interstate or foreign commerce to place sports bets.
The prosecutor noted: "An Internet communication is no different than a
telephone call for purpose of liability under the Wire Wager Act."
[Reuters/*The New York Times*, 11 Aug 2000; NewsScan Daily, 11 August 2000;
http://partners.nytimes.com/library/tech/00/08/biztech/articles/11gambling.html]


County blew $38 million on canceled payroll system!

<"Joan Brewer" <pegasus@transport.com>>
Mon, 31 Jul 2000 07:44:08 -0700

The managers of King County's unfinished $38 million Financial Systems
Replacement Program (FSRP) computer system did not use basic computer and
business procedures, forcing part of the system online before it was ready,
spending the rest of their budget trying to fix the resulting problems, and
leading to the cancellation of the project, largely because of delays and
cost overruns in the payroll system for the county's 19,000 employees.  The
resulting system reportedly can handle only one-third of the load.  [Source:
Article by Roberto Sanchez, County blew $38 million: Here's what went wrong,
*The Seattle Times*, 28 July 2000; PGN-ed]


Delays in the new UK Air traffic control system (Re: RISKS-20.93,94)

<Ursula Martin <ursula@csl.sri.com>>
Thu, 10 Aug 2000 10:41:39 -0700

400 technicians (software engineers perhaps?) have reduced the number
of [known] bugs from 500 to 200 in recent weeks.
[See http://news.bbc.co.uk/hi/english/uk/newsid_873000/873765.stm]


Microsoft vulnerabilities, publicity, and virus-based fixes

<Bruce Schneier <schneier@counterpane.com>>
Mon, 07 Aug 2000 09:07:45 -0500

The latest tale of security gaps in Microsoft Corp.'s software is a
complicated story, and there are a lot of lessons to take away ... so let's
take it chronologically.

On June 27th, Georgi Gunniski discovered a new vulnerability in Internet
Explorer (4.0 or higher) and Microsoft Access (97 or 2000), running on
Windows (95, 98, NT 4.0, 2000).  An attacker can compromise a user's system
by getting the user to read an HTML e-mail message (not an attachment) or
visit a website.

This is a serious problem, and has the potential to result in new and
virulent malware.  But it requires Microsoft Access to be installed on the
victim's computer, which, while common, is by no means universal.  A virus
that exploits this vulnerability will not spread as widely as, say,
Melissa.  In any case, Microsoft published a fix on July 14th, and I urge
everyone to install it.

On July 17th, SANS promulgated an e-mail warning people of the "most
dangerous flaw found in Windows workstations."  I can't really figure this
e-mail out; it seems to be primarily a grab for press coverage.  Some of it
is suspiciously vague: "We developed this exploit further and realized that
this is one of the most serious exploits of Windows workstations in the
last several years"  "Developed"?  How?  No one says.  Some of it brags:
"Microsoft asked us not to release the details until they had a
fix."  "Release the details"?  But the original Bugtraq posting was pretty
explanatory, and SANS has not released anything new.

Still, the SANS e-mail received a lot more publicity than the Bugtraq
announcement or the Microsoft patch, so it's hard to complain too much.

But the SANS announcement had a much more disturbing section:  "It may be
possible to fix this vulnerability automatically, via an email without
asking every user to take action. The concept is similar to using a
slightly modified version of a virus to provide immunity against infection.
SANS is offering a $500 prize (and a few minutes of fame) to the first
person who sends us a practical automated solution that companies can use,
quickly, easily, and (relatively) painlessly to protect all vulnerable
systems."  (This paragraph is no longer on the website, which claims that
"winning entries have been received.")

This is a really, really dumb idea, and we should put a stop to this kind
of thinking immediately.  Every once in a while someone comes up with the
idea of using viruses for good.  Writing a virus that exploits a particular
security vulnerability in order to close that vulnerability sounds
particularly poetic.

First, there's no audit trail of the patch.  No system administrator wants
to say: "Well, I did try and infect our systems with a virus to fix the
problem, but I don't know if it worked in every case."

Second, there's no way to test that the virus will work properly on the
Internet.  Would it clog up mail servers and shut down networks?  Would it
properly self-destruct when all mail clients were patched?  How would it
deal with multiple copies of itself?

And third, it would be easy to get wrong and hard to recover
from.  Experimentation, most of it involuntary, proves that viruses are
very hard to debug successfully.  Some viruses were written to propagate
harmlessly, but did damage because of bugs in their code.  Perfectly
intentional experimentation proves that in your average office environment,
the code that successfully patches one machine won't work on another,
sometimes with fatal results.  Combining the two is fraught with
danger.  Every system administrator who's ever automated software
distribution has had the "I just automatically, with the press of a button,
destroyed the software on hundreds of machines at once!" experience.  And
that's with systems that you can *stop*; self-propagating systems don't
even let you shut them down when you find the problem.

In any case, the SANS announcement was made even more confusing by the
announcement of another Microsoft vulnerability at the same time...one that
I think is even more serious than the one SANS publicized.  (The
vulnerability was first discovered on July 2nd, but was independently
discovered and published on Bugtraq on July 18th.)

A buffer overflow in Microsoft Outlook or Outlook Express allow an attacker
to execute arbitrary code on a victim's machine just by sending him an
email.  In Outlook Express, the victim doesn't even have to open the email,
or preview it.  All he has to do is download it.  In Outlook, he has to
read it.

That's the bad news.  The good news is that it only is a vulnerability for
users who have POP or IMAP installed; those using Outlook's default
corporate configuration are not vulnerable.  (Home users who link to
commercial ISPs are much more likely to be vulnerable.)  So again, a virus
that exploits this vulnerability would be dangerous and unpleasant, but
would not spread unchecked.

Microsoft has a fix.  Originally (on July 18th) it required you to upgrade
your version of Outlook or Outlook express, but two days later Microsoft
did the right thing and issued a patch for all versions.  SANS issued
another e-mail on July 21st, with more dire warnings: "Please fix this
before you go home today.  And if you have gone home, go back to the office
and fix it."  In my opinion, this warning blew the threat completely out of
proportion, and was irresponsible to send.  SANS made it sound like a virus
attack already in progress, not a new vulnerability that someday might be
exploited.  And right on the heels of the previous warning, it got lost in
the noise.  When I received the second SANS e-mail, I thought it was
another reminder for the first vulnerability.  I'll bet that many users
were similarly confused, and ignored it as well.

There are several lessons here.

1.  Computer programs have two sorts of vulnerabilities, nicely illustrated
by these two attacks.  First, they have vulnerabilities connected to the
basic design of the operating system they run on and the way it chooses to
interlink programs; the Access attack demonstrates this.  Second, they have
vulnerabilities based on coding mistakes; the buffer overflow problem is an
example.

2.  It's not enough to release a patch.  The press often gets this
wrong.  They think the sequence is: vulnerability publicized, patch
released, security restored.  In reality, it doesn't work that way.  You
don't regain security until you install the patch.  Even though both of
these vulnerabilities have been patched, I predict attack tools that use
them.  Many users just won't bother installing these patches.  For
publicizing the two vulnerabilities, SANS is to be commended.

3.  Sensationalizing vulnerabilities will backfire.  Both of these
vulnerabilities are serious, but neither is monumental.  Calling something
"the most dangerous flaw" leads people to trivialize other flaws.  I worry
about the public being completely unable to determine what is
important.  We've seen viruses that fizzle, and others that run
rampant.  We've seen vulnerabilities that look serious but don't amount to
anything, and ones that are trivial and exploited again and again.  SANS
needs to be a voice of reason, not of hyperbole.

4.  Writing a virus to exploit a vulnerability is a bad idea, even if the
goal of that virus is to close that vulnerability.  Viruses, by their very
nature, spread in a chaotic and unchecked manner; good system
administration is anything but.

5.  There are still lots of serious vulnerabilities in Microsoft products,
and the interactions between products, waiting to be discovered.

The Access/IE vulnerability:
<http://www.securityfocus.com/bid/1398>
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO47273,00.html>

The SANS announcement:
<http://www.sans.org/newlook/resources/win_flaw.htm>

Microsoft's "work around":
<http://www.microsoft.com/technet/security/bulletin/MS00-049.asp>

The Outlook vulnerability:
<http://www.securityfocus.com/bid/1481>

Reports on the vulnerability:
<http://www.securityfocus.com/news/62>
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO47323,00.html>

Microsoft's fix:
<http://www.microsoft.com/windows/ie/download/critical/patch9.htm>
<http://www.microsoft.com/technet/security/bulletin/ms00-043.asp>

This article originally appeared in:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2609398,00.html>
Bruce Schneier, CTO, Counterpane Internet Security, Inc.  Ph: 408-556-2401
3031 Tisch Way, 100 Plaza East, San Jose, CA 95128       Fax: 408-556-0889


REVIEW: "NT 4 Network Security", Strebe/Perkins/Moncur

<Rob Slade <rslade@sprint.ca>>
Mon, 14 Aug 2000 09:14:54 -0800

BKNT4NSC.RVW   20000609

"NT 4 Network Security", Matthew Strebe/Charles Perkins/
     Michael G. Moncur, 1999, 0-7821-2425-9, U$49.99
%A   Matthew Strebe ntsecurity@starlingtech.com
%A   Charles Perkins ntsecurity@starlingtech.com
%A   Michael G. Moncur mgm@starlingtech.com
%C   1151 Marina Village Parkway, Alameda, CA   94501
%D   1999
%G   0-7821-2425-9
%I   Sybex Computer Books
%O   U$49.99 800-227-2346 Fax: 510-523-2373 info@sybex.com
%P   940 p. + CD-ROM
%T   "NT 4 Network Security, Second Edition"

While dauntingly thick, this is a generally readable, and fairly
comprehensive, introduction to security in general, and particularly to
Windows NT in a networked environment.  On the other hand, it sometimes has
less material than you would expect.

Chapter one presents a general overview of security, touching lightly on a
range of topics and indicating areas the book is going to cover.  It is
interesting to note that one subject seems to be left out: data and business
recovery is only mentioned tangentially.  For example, the NTFS disk format
is noted to fully support security, but the possible problems in recovering
when the disk goes bad are not mentioned.  Human security, in chapter two,
covers a wide range of social factors, including an extensive discussion of
password choice, and the importance of treating your employees fairly and
well.  The explanation of encryption, in chapter three, deals with a number
of important aspects, but is poorly structured.  It also brings in a number
of unrealistic factors, such as the use of quantum computers, and neglects
some fairly important current developments.  A general plan for
administering security is proposed in chapter four.

Chapter five presents the Windows NT security model, and, while it does a
better job than many other such works, it does not really provide a clear
working picture.  User account functions, with another look at passwords, is
reviewed in chapter six.  System policy is introduced in chapter seven, but
the overall operation and effect is not explained well, and the material
almost immediately degenerates into a terse listing of policy options.
Although chapter eight purports to examine file systems, most of it deals
with setting security permissions with NTFS.

Chapter nine starts to look at networking issues with workgroups and shares.
Unfortunately, while the mechanics of sharing operations are clear enough,
the concepts are not.  Domains and trust relationships are introduced, but
not very functionally, in chapter ten.

Fault tolerance, in chapter eleven, gives some basic information on various
types of disk redundance, and a few tips on backup.

Chapter twelve talks about virus protection.  I am used to security texts
that have numerous mistakes in this area, but I was astonished to see, at
the beginning of this section, mention of a "CMOS virus" (no such thing)
that infects the CMOS BIOS code.  A computer's "CMOS" is the term used to
refer to the small chip containing battery supported memory, holding a small
table of information.  This information is used by the BIOS programming,
which programming is generally stored in read-only memory.  (The next page
actually mentions this.)  CMOS memory is generally too small to hold any
effective virus.  In addition, it is only called as data, and no program
that you did manage to store in the CMOS area would ever run.  In any case,
the text goes on to say that these viruses can obtain complete control over
a computer, and cannot be removed by most antiviral software.  (I suppose
the statement about removal is true enough: since they don't exist, who
would bother to write removal programs?)  There is also an erroneous account
of the Brain virus, a two page exegesis on Java that finally admits Java
can't be used to create viral applets, a statement that NT is "immune" to
file viruses (it's not), a list of antiviral types that only mentions
different types of scanners (never mentioning activity monitors or change
detection software), and a section on trojan software.

Remote access actually starts with a brief mention, at the end of chapter
twelve, of the dangers of pcAnywhere.  (Both here and in the following,
there are stories of scanning local networks from home ISP service.  The
authors do not mention that this operation is restricted to those with cable
modems.)  Chapter thirteen starts off with some opining on phone phreaking,
but then does move on to some reasonable information on securing dial-in
situations.  The material on multi- vendor networks, in chapter fourteen,
does little more than assert that other operating systems have security
holes, too, you know!  Chapter fifteen is an introduction to the Internet,
but, because of a rather loose structure, does not present security concepts
in a coherent manner.  Similarly, the overview of TCP/IP, in chapter
sixteen, lists a number of potential problems with the protocols but not
much instruction on what to do about them.

Chapter seventeen describes a rather random bag of advice on security
aspects on client (non-server, or, in other words, user) machines.  Then we
move back into network territory with a blend of firewall and virtual
private network (VPN) technology in chapter eighteen.  Chapter nineteen
tells us about VPNs, with a few mentions of firewalls.  Microsoft BackOffice
is reviewed in chapter twenty, but without much specific information about
security.

Chapter twenty one lists a variety of user (application) level
security loopholes.  A number of attacks available at the network
level are listed in chapter twenty two.  "The Secure Server," in
chapter twenty three, looks primarily at physical security and
concerns (and finally admits that NTFS can be bypassed after all).
Chapter twenty four looks at physical matters again, mostly in the
TEMPEST realm (and with a little misinformation about fibre optics and
fish tanks).

The authors have tried to lighten up a rather heavy topic by including
humour in the text.  While the remarks don't really get in the way of the
content, they don't really support it, either.  There is also an attempt to
keep readers from getting lost in the jargon by providing "terminology"
boxes throughout the book.  This is helpful, but is not used as consistently
as it could be.  Acronyms, in particular, frequently start to appear in the
text without ever having been specifically defined.

This work has better conceptual coverage than "Microsoft Windows NT 4.0
Security, Audit, and Control" by James G. Jumes et al, (cf. BKWNTSAC.RVW),
and is about equal to "Windows NT Server 4 Security Handbook" by Hadfield,
Hatter, and Bixler (cf. BKNT4SHB.RVW).  There is better structure and more
willingness to discuss flaws than is apparent in the "Windows NT Security
Guide" by Stephen A. Sutton (cf. BKWNTSCG.RVW).  It has perhaps the same
level of quality, and is certainly larger than "Windows NT Security" by
Charles B. Rutstein (cf. BKWNTSEC.RVW), but there is not as much depth in
places.  "PCWeek Microsoft Windows NT Security," by Lambert and Patel (cf.
BKPWNTSG.RVW), has better material in significantly less space.  In terms of
Internet material, it is about the same as "Internet Security with Windows
NT," by Mark Joseph Edwards (cf. BKINSCNT.RVW), although it could hardly be
worse.  In general it is a good, useful guide, but there are still a number
of holes to patch.

copyright Robert M. Slade, 2000   BKNT4NSC.RVW   20000609
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

x
Top