The RISKS Digest
Volume 19 Issue 91

Thursday, 13th August 1998

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…


Titan IV explodes with Vortex satellite; cost over $1B
Global War[m|n|p|r]ing?
"John-the-Ripper" software collects passwords
Unix passwords no longer safe
Chiaki Ishikawa
linux on submarines
Perils of rushing to market
Mich Kabay
Re: USS Yorktown: WinNT --not?-- the fault
Nathan Myers
Phil Edwards
Martin Ward
Re: Software flaw exposes e-mail programs ...
Li Gong
Win98 Yx problem, not Y2K?
Scot E. Wilcoxon
CFP - 1999 IEEE Symposium on Security and Privacy
Mike Reiter
REVIEW: "Time Bomb 2000", Edward Yourdon/Jennifer Yourdon
Rob Slade
Info on RISKS (comp.risks)

Titan IV explodes with Vortex satellite; cost over $1B

"Peter G. Neumann" <>
Thu, 13 Aug 1998 8:12:39 PDT
The Lockheed-Martin Titan IV that began self-destructing at 20,000 feet only
40 seconds after liftoff from Cape Canaveral carried a top-secret satellite
(code-named Vortex) for the U.S. National Reconnaissance Office.  It was
destroyed on ground command two seconds later.  The Air Force gave no
information on the cause.  This was the last launch for this Titan IV model;
future launches are already scheduled to use an improved model.  [Source:
Reuters item, 13 Aug 1998; PGN Abstracting]

Only two failures out of 25 launches is reportedly thought to be a
reasonably good record, although this loss is expensive — $300M for the
Titan, and between $800M and $1B for the satellite.  Associated Press noted
that a previous Titan IV failure occurred from Vandenberg AFB in August 1993
(ignoring the Titan IV that blew up on the test stand on 1 April 1991 — see
RISKS-12.09 — as a result of a problem that seemingly could have been
caught in simulation).

Global War[m|n|p|r]ing?

"Peter G. Neumann" <>
Thu, 13 Aug 1998 8:16:22 PDT
Despite rampant evidence of global warming, satellite evidence over the past
20 years has been suggesting that the earth's atmosphere is cooling.  Frank
J. Wentz and Matthias Schabel, scientists at Remote Sensing Systems in Santa
Rosa, California, have published a study in *Nature* (out today) that
concludes that atmospheric temperatures have in fact increased, and that the
previous satellite data was erroneous — in part because orbiting
thermometers lose altitude and in part because of the computers.  The
argument based on the global warping of orbits continues the global warring
among scientists and policy makers as to whether there really is global
warming that merits global warning.  [Source" *The Washington Post*, 13 Aug
1998; PGN Abstracting]

If you happen to have particular faith in satellite data, please don't
forget Bill McGarry's report in RISKS-3.29 about how the very clear early
warning of ozone-layer depletion over the South Pole was ignored for many
years because the dramatic data values were rejected by the software --
because they were so extreme.  That case is one of the rare examples of a
bounds check that *should have* been missing (as opposed to all of the
missing bounds checks that we report in RISKS as causing security flaws or
other problems).

"John-the-Ripper" software collects passwords

"Peter G. Neumann" <>
Thu, 13 Aug 1998 8:12:39 PDT
Michael Kleber, a UC Berkeley Sys Admin, discovered that someone had cracked
his password, and was using his account — having already successfully
cracked over 48,000 passwords from a list of 186,126 encrypted passwords.
From Berkeley, the cracker broke into systems at "a noted Silicon Valley
company", an Indiana ISP, other UCBerkeley systems, Caltech, MIT, and
Harvard, having used a Swedish ISP Telenordia, and coming through computers
in England, Denmark, and South Korea.  He was finally detected on 29 Jun
1998.  [Source: Henry K. Lee, *San Francisco Chronicle*, 13 Aug 1998, A21]

Incidentally, pending U.S. legislation on copyright protection would make it
illegal to crack passwords, but as a side-effect would also make it illegal
for sys admins to find out which passwords on their systems were easily
crackable — as well as outlawing reverse engineering to do constructive
security analysis!  That is a law that would have very little effect on
foreign crackers, and could have a serious effect in further dumbing down
system and network security, which is already pitiful in many cases — as
readers of RISKS are well aware.

Unix passwords no longer safe

Chiaki Ishikawa <>
Wed, 12 Aug 1998 06:09:56 +0900 (JST)
Re: "Cracking DES" (Gilmore, RISKS-19.87)

The successful cracking of DES by brute force using a farm of dedicated
chips has also brought force the danger of Unix password compromises in a
new light.

Now we can target the root account for compromise attempt.

Most readers of RISKS are by now familiar with the basic concepts, but here
it goes again:

- Traditionally, UNIX uses one-way function (a twist on DES, detail later)
  to store user password in encrypted form.   Usually /etc/passwd.
  The shadow password scheme leaves the old /etc/passwd less the encrypted
  field for backward compatibility and uses another file (only root can read
  it) to store the encrypted field.

- When the user logs in, the typed password is encrypted and the result is
  compared with the stored encrypted password.  If they match, the
  authentication succeeds.

The best known attack to Unix password scheme is to steal/copy the password
file where the encrypted passwords are stored and then encrypt a
"dictionary" of common words and popular phrases and see if the result of
encryption of a phrase matches the entry in the password file.  The best
known program, Crack by Allec Muffet, works in this manner.

The more words that are in the dictionary, the greater the chance of
cracking some accounts in the given password file.  Please note that a
particular user's account is still hard to crack.  The idea of Crack to weed
out the weak passwords from a collection of passwords, not particularly for
cracking a single password entry.  Cracking a few ordinary user accounts is
enough for evil crackers to use that host for gathering local information
and then use it as a launching ground for another attack on other hosts.
Crack is meant to plug such holes.

The encryption used for traditional Unix password system is a variation of
DES algorithm. [1]

Traditionally the password is 8 characters maximum.  The 8 seven-bit
character codes are used as the initial DES-like algorithm key to encrypt a
constant to produce the encrypted form of the password.

From what I read about the DES cracking LSI, I think it would be as
easy/difficult to implement an LSI that performs the encryption algorithm of
the traditional UNIX password system.

Given the availability of DES cracking LSI farm, the availability of a
similar system of cracking UNIX password of a "GIVEN USER" once the password
file is available is within our reach.

Please note that this system can pin-point a single user account as its
target, usually root. This was not quite possible with Crack, for example.
(yes, if the root user chooses a simple word such as cocacola or something
like it, then it could have been cracked using Crack.  But something like
"1,#Oa0l'" would have been hard unless the particular phrase was in the
dictionary. But it seems that we can now generate these random strings one
by one and compare and exhaust the candidates within a month!?)  [LESS!]

Given the profit of breaking such account, I assume that major intelligent
gathering organizations and crime organizations are either in the possession
of such cracking system or building one now, I suppose.

Yes, it is a good thing that

 - at least many systems now supports shadow password file, (But this can be
circumvented by application program failure.  A pop3 mail server is known to
leave the encrypted password entry from the shadow file for comparison in
memory when the password didn't match, and a known buffer overflow problem
immediately after the failed comparison can dump core with the password
entry in it. I read about this in BugTraq lately.)

 - some Unix-like systems use different algorithms such as use of MD5 as one
way function.  This avoids the danger from such a cracking system discussed


[1] Password Security: A Case History
    Robert Morris and Ken Thompson
    AT&  Bell Laboratories, Murray Hill, NJ
   (My copy is part of the BSD manual set published by O'Reilly.)

To quote from that reference, section 4:

"4. The Threat of the DES Chip

Chips to perform the DES encryption are already commercially available and
they are very fast.  The use of such a chip speeds up the process of
password hunting by three orders of magnitude.  To avert this possibility,
one of the internal tables of the DES algorithm (in particular, the
so-called E-table) is changed in a way that depends on the 12-bit random
number.  The E-table is inseparably wired into the DES chip, so that the
commercial chip cannot be used.  Obviously, the bad guy could have his own
chip designed and built, but the cost would be unthinkable."

Unthinkable indeed more than 20 years ago!

I think the slight variation on DES by using the use of salt (the mentioned
12-bit random number) to make the stock DES algorithm chip unusable may no
longer be viable to protect a user account.

Of course, I am assuming that the building of such an LSI is as
easy/difficult as the DES LSI. E-table modification may result in a much
slowdown even in the case of LSI implementation.  (Anyone who knows the
details of the circuit implementation care to comment?)

But in any case, a large organization that still use old, say, SunOS 4.1.4
without shadow password facility installed, or use such system for, again,
old NIS server needs to think of at least installing the shadow password
facility or moving over to the next generation of OS that supports different
authentication scheme.

I know of one Japanese ISP using a Sun system in the above configured manner
:-( Gosh, they could be the rampant attack launching ground within the next
12 months or so...  I hope peer pressure will move such sites into modern

Chiaki Ishikawa,  Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051

  [RISKS readers must be tired of my saying that fixed reusable passwords
  are a menace, irrespectively of how long they are, how full of funny
  characters, how often they are changed (of course, sniffing catches all
  changes), how they are managed, etc.  It is time to retire them.  PGN]

linux on submarines

jay <>
Mon, 10 Aug 1998 16:38:22 -0400 (EDT)
After reading about all of the navy's woes with NT, perhaps they should
listen to the folks at MIT.  MIT has created an automatic sub which runs
Linux.  No GPF's at 20000ft for me.

Perils of rushing to market

Mich Kabay <>
Wed, 12 Aug 1998 14:47:45 -0400
I bought McAfee's PC Medic 97 Deluxe package a week ago.  The QuickBackup
program version 2.04 for Windows failed to perform a total backup; many
files were not copied.

Network Associates' Web site reveals a known problem: version 2.04 cannot
backup files from directories whose names contain a blank space.  Solution:
download version 2.05 from the Web site.

- From NAI customer service, I received the product ID and password required
for the download.  Unfortunately, the file reference for the download
results in a 404 error; seems the download file is not on the server.

This is a wonderful example to include in my quality assurance courses.  I
try to get across the concept that QA is not an add-on — it must inform all
aspects and stages of software development and delivery.  The same, BTW, is
true of security — security is a process, not an end state.

M. E. Kabay, PhD, CISSP / Director of Education,  ICSA Inc. — Carlisle,
PA <>

Re: USS Yorktown: WinNT --not?-- the fault (Fraser, RISKS-19.90)

Nathan Myers <>
Fri, 7 Aug 1998 16:43:57 -0700 (PDT)
> That sounds like a bug in an application program, not the
> esteemed operating system!

I don't know who "esteems" NT, but if somebody entering a zero kept me
from getting under steam for two hours, I would be "steamed" myself.

It doesn't matter what "caused" the outage.  If a program failure can
kill the engine, then a system failure could equally well do likewise.
NT's habit of crashing frequently is well-documented.  Future releases
(with a predicted 65%+ of code replaced!) promise no better stability.

What's the RISK, here?  It looks to me as if the Navy brass decided
to "standardize" on technology that their own technical experts had
warned against relying on, and actually deployed the system before
they were forced to admit its flaws.  Full E-Steam Ahead!

Nathan Myers

Re: USS Yorktown: WinNT --not?-- the fault (Fraser, RISKS-19.90)

"Phil Edwards" <>
Wed, 12 Aug 1998 11:27:41 +0100
I could talk about crash protection and task isolation and threads, but I
think there's a more interesting point here (and a whole new risk).

The official account of the fault, by Vice Admiral Henry Giffin, was quoted
as follows:

The Yorktown lost control of its propulsion system because its computers
were unable to divide by the number zero ... The Yorktown's Standard
Monitoring Control System administrator entered zero into the data field for
the Remote Data Base Manager program. That caused the database to overflow
and crash all LAN consoles and miniature remote terminal units. The program
administrators are trained to bypass a bad data field and change the value
if such a problem occurs again.  [endquote]

The question is whether we accept this as a factual account of what
happened.  I'd argue that there are very good reasons for scepticism. In my
experience, users' accounts of system problems very rarely match what
actually went on - to be more precise, there are correspondences, but it
takes work to identify them.  An account from a non-technical senior manager
who wasn't directly involved is still less likely to be accurate in any
unproblematic way.

So, can we trust Giffin's account? I doubt strongly that the "Remote Data
Base Database?] Manager" program has a singular "data field" and I don't
think there's any such thing as a "LAN console". More to the point, I don't
know what could possibly be meant by "caus[ing] the database to overflow";
or how any sort of DBMS "overflow" could bring down a network server; or how
a network crash could disable a ship's propulsion system (although *that*
may be precisely the problem).

In short, technically speaking it's horse feathers. We know there was a
crash; we can reasonably assume that it had something to do with a division
by zero.  Beyond that I'm sceptical in the extreme. My reading of the story
is that NT Server blue-screened for no apparent reason (as it does) and
displayed a message about a division by zero (as it does - a contributor to
another list reported seeing div/0 crashes in every version of Windows since

Unfortunately we're never likely to get a fuller (or, I'd argue, more
accurate) account than Giffin's. The risk here is the kind of poor
communication with the technical front-line which allows user stories to
spread and be taken literally.  Inadequate problem analysis leads to
inappropriate remedial measures, giving you the worst of both worlds: an
unstable OS, plus an extra layer of procedures and training to ensure that
sysadmins know how to "bypass a bad data field and change the value".

But I may be wrong.

Phil Edwards  Editor, Windows NTexplorer,

Re: USS Yorktown: WinNT --not?-- the fault (Fraser, RISKS-19.90)

Martin Ward <>
Wed, 12 Aug 1998 11:44:07 +0100 (BST)
The whole point is that a decent operating system should not be capable of
being crashed by an application program. My Sun machine has been running
continuously for the last 8 months (until the power cut this morning :-( ):
during that time it has been hammered by buggy development software, without

The same "shifting of the blame" was seen in the NatWest bank case: a bug in
NatWest's application caused NT to crash, yet NatWest are continuing to use
NT despite this fundamental flaw.

The next stage in blame shifting is to blame the user for entering a zero:
with the fix being to hang a big sign over the terminal "Please don't enter
a zero into this program". This reminds me of the old spy movies where the
SuperVillain's Secret Base always had a large red button labelled "Secret
Base Self-Destruct System"... Erdos number: 4
Maintainer of the G.K.Chesterton web site:

Re: Software flaw exposes e-mail programs ... (Haahr, RISKS-19.90)

Li Gong <gong@games.Eng.Sun.COM>
Wed, 12 Aug 1998 16:37:55 -0700
    What all the reports I've read appear to be missing is that bugs
    like this are almost inevitable in C or C++, yet pose almost no
    security issues in safer programming languages, including as Java,
    Lisp, Ada, Smalltalk, Modula-3, Eiffel, ML, etc.

Not only the advantages of Java were glossed over or totally missed by some
of these reports, some others even positively singled out Java as if it is
the most dangerous and insecure technology.  After the latest Eudora
security bug was found, Qualcomm sent the following notice to all registered

    QUALCOMM recently identified that a potential security risk
    existed in Eudora Pro Email 4.0 for Windows and Eudora Pro Email
    4.0.1 for Windows.
    This security risk involves the ability to include user hostile
    Java applets or scripts in an email message.

Note the causal use of "Java applets or scripts".  The real bug is that
Eudora would blindly launch the appropriate applications to process attached
content, and in some case, this would result in some executables being run.
There is nothing here that is Java specific.  The executables can be many
different things.

But by lumping everything together and then calling it "Java applets or
scripts", the announcement is grossly misleading, is creating unnecessary
confusion in the mind of the customers, and is in fact tarnishing the unique
strength and advantage in security that Java has over other competing
Internet oriented technologies.

For an analogy of what Qualcomm said, imagine that you see such an official
notice being posted all over San Diego (where Qualcomm is headquartered):

    Warning!  Due to an electrical problem on our part, all door locks
    are no long working.  To prevent theft, please do not leave
    valuables in your offices, because of the risk that Qualcomm
    employees and some other people may steal them.

What would you think upon seeing this notice?

Li Gong, Java Security Architect, Java Software, Sun Microsystems

Win98 Yx problem, not Y2K?

Tue, 11 Aug 1998 12:13:38 -0500 (CDT)
I'm a Linux user and don't have Win98 around to test this, but I've found
two reports so far today that Win98 has a date problem.

A Y2K test program in the UK reported a Y2K problem, but further testing
revealed that it was not a Y2K problem.  The date was a day or two off
when crossing between any two years.  Because it happens every year and
not only in 2000, it is not a Y2K bug.

You might want to try to mess up the nearest Win98 machine to confirm
this before reporting it...and I don't expect this report to be used
with exactly this phrasing, as I expect you'll find plenty of other sources
with better information.  (OK, so I can even tell an editor that I know
he'll do his job :-)

I saw one report on the BBS web page and now a second related one at
  [Sorry, I cannot include the user code.  PGN]

As these are reports from the UK, I don't know if the problem is sensitive
to the British Isles or GMT time zones or not.  One can hope there is
something more complex than just a date sensitivity, as one's eyebrows tend
to get stuck to the ceiling when a major product has such a problem this
close to Y2K.

Scot E. Wilcoxon

CFP - 1999 IEEE Symposium on Security and Privacy

Mike Reiter <>
Sun, 9 Aug 1998 19:50:32 -0400 (EDT)
The call-for-papers for the 1999 IEEE Symposium on Security
and Privacy is now available at

- Mike

REVIEW: "Time Bomb 2000", Edward Yourdon/Jennifer Yourdon

"Rob Slade, doting grandpa of Ryan and Trevor" <>
Wed, 12 Aug 1998 11:13:24 -0800
BKTMBM2K.RVW   980531

"Time Bomb 2000", Edward Yourdon/Jennifer Yourdon, 1998,
0-13-095284-2, U$19.95/C$27.95
%A   Edward Yourdon
%A   Jennifer Yourdon
%C   One Lake St., Upper Saddle River, NJ   07458
%D   1998
%G   0-13-095284-2
%I   Prentice Hall
%O   U$19.95/C$27.95 201-236-7139 fax: 201-236-7131
%P   416 p.
%T   "Time Bomb 2000: What the Year 2000 Computer Crisis Means to You"

It doesn't take long to figure out which Saturday morning is being referred
to in the Preface.  And one of the common failures suggested by pundits
after December 31, 1999, is that of phone service.  As the outage extends to
a decade, however, one begins to wonder how realistic this book is going to
be.  For one thing, loss of dial tone is much less likely than billing
errors, and the most likely errors would be failure to bill for those calls
taking place as midnight (switch time) strikes.  However, the introduction
goes on to point out that the subtitle is much more appropriate to this
book: it is addressed to the non-technical audience, rather than those
charged with fixing the problem.  A bit of overstatement can therefore be
forgiven.  It is odd, though, that so many of the examples used refer to
large infrastructures: what *could* the normal citizen do if faced with a
region wide water outage?

Chapter one introduces the concepts of risk management and planning, and
stresses the relative time elements to plan for.  However, one of the
central statements is that we simply do not know what is going to happen,
and that makes planning rather difficult.  There are some general
suggestions (for example, that most disruptions will be of days, rather than
weeks, duration), but even these are questionable.  One specific
recommendation, for instance, is that stockpiling a month's supply of food
in a city apartment might be difficult, so maybe you should go visit friends
in the country for a month.  I'm not sure what assumption this is based on,
but if food distribution is interrupted, it might be more likely that
emergency food provision would be concentrated in population centres.  The
consequences to employment are reviewed in chapter two, which ultimately
suggests only one course of action: have a nest egg on hand.  The scenario
is alarming, but also possibly unduly optimistic, since it repeatedly
suggests planning for a year out of work.  Using the book's own figures, and
fairly simple arithmetic, the average time out of work would appear to be
four years.  The discussion of utility disruption, in chapter three, is
vague and offers little in the way of practical suggestions.  Interconnected
failures are not emphasized (gas furnaces fail as soon as electrical
thermostats shut down) and food stockpiling is probably not realistic (how
many foods require no refrigeration for storage and no heating for

Given the heavy business emphasis in other areas, it is odd to note that the
concern for transportation is limited to personal travel in chapter four.
While a sudden transition to telecommuting would have a major effect on
business (and be impossible for some), the failure of shipping is much more
serious.  Chapter five's assessment of the banking industry could be
responsible for a run on the banks, itself.  (The advice to keep hardcopy of
all transactions in the months preceding and following December 31, 1999 is
very good.)  The problems of the advice regarding food in chapter six have
already been addressed, since the material basically repeats, in more
detail, what has already been said elsewhere.  Home computer problems are
really only looked at in terms of business use of PCs in chapter seven.  I
am rather interested to note that the Internet does not get a mention either
in regard to personal computers or in relation to news and information in
chapter eight.  The overview of medical care, in chapter nine, is solid,
careful, and useful.

While I agree that government is one of the largest, and most tardy,
potential victims of Y2K, chapter ten is shortsighted in seeing it
only as a provider of cheques.  As with much of the rest of the book,
the information in this section is US-centric, although similar
concepts apply elsewhere.  Chapter eleven reviews embedded computers,
but only broadens the scope of what could happen in other areas.  This
material should probably have been included earlier in the general
discussion of the problem.  Education, as all too often, seems to be a
bit of an afterthought, but some important points are made in the
relatively short chapter twelve.  Chapter thirteen notes that
communication is an obvious target, and so most likely to be
adequately addressed by the deadline.  That is good, since the book
gives no realistic advice for fallback positions.  (A cell phone will
be just as dead as a land line if all the switches are down, and is
much more likely to have problems in the handset.)

Despite the many shortcomings of the book, I do feel that it should be read
and considered by a good many people.  The books and articles currently
extent concentrate on the problem and necessary solutions from a systems and
technical perspective.  There is a need for some consideration about
personal actions that can be taken to ameliorate potential problems.
Hopefully this discussion can have some rationality behind it: producing a
run on the banks or dry soup mix in December '99 will help nobody.

copyright Robert M. Slade, 1998   BKTMBM2K.RVW   980531

Please report problems with the web pages to the maintainer