Subject: RISKS DIGEST 17.31
REPLY-TO:
[email protected]
RISKS-LIST: Risks-Forum Digest Tues 29 August 1995 Volume 17 : Issue 31
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, etc. *****
Contents:
US White House Hacked? (David Kennedy and Mich Kabay)
REVIEW: Computer Crime: A Crimefighter's Handbook (R. Joseph Loughry)
Warning on MSN Icons (Edupage)
Information on Winword virus (PC/Mac) (Paul Ducklin)
Taunting the lions [more on the year 2000] (Bear Giles)
Re: Risks of automatic newspaper publishing (Bear Giles, Mark Seecof)
Re: Dumpster diving on the Information Superhighway (Peter da Silva)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: 28 Aug 95 23:01:50 EDT
From: David Kennedy <
[email protected]>
Subject: US White House Hacked?
[German Press Agency, 20 Aug 1995, Received in German through the Executive
News Service of CompuServe. First pass machine translation by GlobaLink
Power Translator v. 1.0; errors in translation by David M. Kennedy & Michel
E. Kabay]
German Hacker in White House Computer Annoys the Internet
By Justus Demmer, German Press Agency
Hamburg (German Press Agency) - Among those familiar with the Information
Superhighway, there are certain rules of behavior: Netiquette. In the last
week, German hackers have broken with Netiquette, offending some users of
the global network of some 30 million computer users by sending a message
accusing users of attempting to penetrate the US White House's computers.
The alleged sender of these messages? President Bill Clinton.
An article in the German Computer Magazine "c't," published in Hanover,
broke the news. However the messages leave telltales of their German origin,
which tipped off the Systems Administrator in the White House who in turn
notified the German Computer Emergency Response Team, DFN-CERT.
DFN-CERT functions as a kind of fire department for the Internet. They
identified the "Clinton-Mails" as fakemail according to the magazine's
article. DFN-CERT acted but withheld news of the attacks.
[DMK: So apparently did the White House. Possibly one of the many Sendmail
holes?]
DFN-CERT staff member Uwe Ellerman said Internet users, and especially
magazines, have a responsibility to acknowledge attacks. However many do
not want to admit they were penetrated. Ellerman said that the press
should report these matters. The magazine should make their own computers
available for such silly tricks if they wish.
However, explained c't editor Georg Schnurer, that has not been the case.
He claimed the White House uses an old version of software for electronic
mail handling which is obsolete. This program makes it possible to falsify
mail. Many other System Administrators also use this older version,
leaving the network vulnerable to similar attacks.
[DMK: More pointers towards Sendmail. More pointers to why it should be
acknowledged so that the clueless will check for Sendmail holes. Possibly
confirming fact, the recent US CERT Sendmail Alert.]
Ellerman and Schnurer do not agree whether public notice of the White
House error was necessary or not, they do agree that to maintain integrity
over their mail, users should encrypt their mail.
David Kennedy / Vol.SysOp Natl Computer Security Assn Forum on CompuServe
GO:NCSAFORUM
M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: Mon, 28 Aug 95 15:42:49 PDT
From:
[email protected] (R. Joseph Loughry)
Subject: REVIEW: Computer Crime: A Crimefighter's Handbook
REVIEW: Computer Crime: A Crimefighter's Handbook, by David Icove, Karl
Seger, and William VonStorch. Published by OReilly & Associates, Inc.,
August 1995. 437 pages, with index. ISBN: 1-56592-086-4.
COMPUTER CRIME: A CRIMEFIGHTER'S HANDBOOK was derived from an FBI training
manual on the prevention and investigation of computer crimes. It delivers
a wide-ranging, non-technical overview of computer system vulnerabilities,
threat assessment, and the law.
Covering the gamut from unlawful intrusion to poisoning of computer
operations staff, this book provides an excellent introduction to threat
assessment and security procedures for protecting an organization from
computer crime. Unlike most computer security books aimed at system
administrators, this one is written from the perspective of law
enforcement, and describes what to do before, during, and after a
computer crime is discovered.
The book is divided into five parts. The first part of the book
describes vulnerabilities, threats, and countermeasures, with equal
emphasis given to the human components of a system as well as technical
issues. The section on Social Engineering is well illustrated, if a bit
too short, and some of the more obscure possibilities for covert
channels and compromising emanations are well covered. The discussion
suffers from a lack of references to documented attacks (see below), and
a somewhat confusing explanation of the differences between Trojan
Horses, viruses, worms, and logic bombs. Chapter 5, on risk assessment,
nonetheless is excellent.
Physical, personnel, and communications security are covered in the
remainder of Part II. One exposure that I thought was not mentioned
highly enough is the vulnerability of backup media to theft. Dumpster
diving is discussed in some detail (together with a humorous and
totally unnecessary diagram).
I would have liked to see references given for many of the examples of
computer crimes scattered throughout the book. Some of the descriptions
edge toward hyperbole; more complete references would allow the reader
to pursue further information if needed. Two of the appendices, written
by John Gales Sauls and Michael G. Noblett, are liberally referenced.
Part III of the book is the most unusual. It is essentially a checklist
for the professional investigator who needs to collect and preserve
evidence of a computer crime. Much detail is presented on the
identification and preservation of anything even remotely related to a
criminal investigation (within the bounds of the required search
warrant, of course). Appendix D contains the full text of an actual
search warrant used in an investigation in 1994, which makes for
fascinating reading.
It is interesting to compare these chapters with the Foreword, in which
Chris Goggans describes a search of his home by the U.S. Secret Service
in 1990.
Part IV contains the text of laws covering computer and communications
security in the United States at the level of Federal and State courts.
The text of a proposed computer crime law from Ghana is also included,
for completeness.
Appendices list books, organizations, electronic resources and
governmental agencies responsible for computer security. These
appendices are not nearly as detailed as those provided in COMPUTER
SECURITY BASICS, by Deborah Russell and G.T. Gangemi, Sr. (ISBN: 0-
937175-71-4), another book published by OReilly & Associates. Together,
the two books complement one another perfectly.
Joe Loughry, Distributed Systems Department, First Interstate Bank
[email protected] [Usual disclaimers implied. PGN]
------------------------------
Date: Tue, 29 Aug 1995 08:04:38 -0400
From:
[email protected] (Edupage)
Subject: Warning on MSN Icons (Edupage, 27 Aug 1995)
A new convenience included in Microsoft Network e-mail processing could
present a loophole for invading computer viruses, warn some security
experts. When an MSN user sends a binary file as part of an e-mail message,
it appears as an icon on the recipient's screen. When the recipient
double-clicks on it, it's automatically downloaded and executed. To
download without executing the file, the recipient must click with the
little-used button on the right of the mouse. "On the Microsoft Network, I
can disguise an icon so that it looks innocuous," says the VP and chief
technical officer for Interactive Data Corp. "The analogy I like to use is
the Unabomber. If you get a package in the mail that's wrapped in duct tape
and brown paper, you'd regard it as suspicious. But if it's a plain white
envelope with Ed McMahon's picture on it, you wouldn't think twice about
opening it." Microsoft responds that "There are risks of getting data off
the network in any form. People have to be aware of what the source of
information is." (Information Week, 28 Aug 1995, p24)
[Also noted by Monty Solomon <
[email protected]>. PGN]
------------------------------
Date: Tue, 29 Aug 1995 12:49:11 EDT
From: VIRUS-L Moderator <
[email protected]>
Subject: VIRUS-L Digest V8 #73
FROM VIRUS-L Digest Tuesday, 29 Aug 1995 Volume 8 : Issue 73
Date: Thu, 24 Aug 95 12:45:15 +0100
From: Paul Ducklin <
[email protected]>
Subject: Information on Winword virus (PC/Mac)
As many of you will know, there's a Microsoft Word macro virus out there
(variously known as "Winword.Concept", "WW6Macro" and "Prank Macro") that
has apparently made it into the wild. The idea of macro-language viruses is
not new -- indeed, AFAIR, Prof H. J. Highland, editor of Computers &
Security, demonstrated the possiblity under Lotus 1-2-3 several years ago.
What is new is that this Word macro virus seems to be in the wild, and that
it seems to be driving people wild. Certainly, news wires are abuzz. If we
believe what we're told, it's the End Of Computing As We Know It (again :-).
The concept is obvious, and has been much discussed. Most products can read
and write data files; some allow their data files to contain programmatic
commands that would more typically be typed at the keyboard or issued with a
mouse. The idea is that when you load a data file with a "command script" or
"macro" in it, you can carry out a whole sequence of program functions
automatically -- rather than having to type them in over and over again.
Many programs with macro support allow their macros to access a substantial
range of functions, such as opening, manipulating and closing files -- or
even issuing direct operating system commands. Some macro systems go even
further -- they allow macros to be mixed with regular data files, and they
define special types of macro (typically identified by a predefined name, or
position) which will automatically be fired up when a file is loaded or the
system is started. DOS has such a system -- no prizes for guessing where the
name AUTOEXEC.BAT comes from.
No prizes, either, for working out that data-file + macro-language +
autoexec-of-special-macros is a formula which works out to a security
nightmare. Viruses, Trojan Horses, modification-of-service attacks -- all
are remarkably possible in such an environment.
MS Word 6.0 has a particularly rich macro language (WordBasic), and a number
of "macro hooks" whereby an unsuspecting user can be lured into executing a
hitherto unseen and unknown macro simply by loading a document. This is how
Winword.Concept works -- we leave the actual details as an exercise to the
reader, for safety's sake.
Winword.Concept is obvious, and easy to handle. Most anti-virus software
users should be able to contact their vendor for help on how to detect and
clean it up (Sophos SWEEP clients certainly can: mail to
[email protected] if you're worried). There is a bigger issue, though,
which you would do well to address *now*. Ask yourself if you are aware of
any "automatic macro" facilities in the software your organisation uses. And
ask yourself if you know how to control the operation and scope of these
facilities.
For example, if you're a WinWord user, did you know that:
* a document can contain an AutoOpen macro, which may be
executed transparently and automatically when that document
is opened?
* a macro, once running, can make changes to a set of global
macros that may end up being transparently included in many
or all documents created in the future?
* there are numerous "automatic" triggers in addition to
AutoOpen that malicious macro code might exploit?
You can see the risk here. You may know, or be told, though, that:
* holding down <Shift> whilst opening a document will inhibit
the invocation of its AutoOpen macro.
* Tools/Options/Save includes an option ("Prompt to save
NORMAL.DOT") which will make transparent changes to your global
macros much less likely.
* that you can instruct WinWord, when you load it, to switch off
"automatic" macros altogether, by loading it with the command
"WINWORD.EXE /mDisableAutoMacros", or by holding down the <Shift>
key as you fire it up.
You may also, like me, try out these fixes and discover that the first and
last don't actually seem to work as suggested! There is a good trick for
WinWord, however: create yourself a global AutoExec macro (this is run when
Word starts up) that looks like this:
Sub MAIN
DisableAutoMacros
MsgBox "Auto Macros are turned off", "Safety First!", 64
End Sub
WinWord.Concept -- and other malware based on AutoOpen -- will not work if
you do this.
Control is in your hands. Don't panic. Take the opportunity to learn more
about features of the software you use, to test and verify any security
features you plan to utilise, and then to configure accordingly. Don't treat
this new Word virus as a nightmare; use it as an opportunity to take stock,
and to learn.
(Commercial sideline: you don't have to be a Sophos client to e-mail
[email protected] -- or try
http://www.sophos.com :-)
Paul Ducklin Sophos Plc + 21 The Quadrant + Abingdon OX14 3YS + England
[email protected]
[Paul also has a followup message in the same issue of VIRUS-L. PGN]
------------------------------
Date: Tue, 29 Aug 95 17:14:53 GMT
From:
[email protected] (Bear Giles)
Subject: Taunting the lions [more on the year 2000]
Two telling excerpts from a Sunday, 27 August 1995 _Denver Post_ article
(page 3B).
2000 May Hold Years of Trouble
4-digit dates bedevil computers
By Patrick O'Driscoll
Denver Post Staff Writer
[Clayton Powers, staff director for Colorado Commission on Information
Management] said "If you wrote really good code, you might put your date
routine in one place. Another programmer may have a date routine 10
times in a program."
Ironically, institutional computer geeks have known about "the year
2000 changeover" for years, to the point it even became an inside joke.
The first paragraph explains why it's the big organizations we need to fear
on the upcoming odometer rollover. Small companies tend to be much more
insistent on at least minimal competence and efficiency. I have a hard time
conceiving of any programmer needing to write a date routine more than once
-- that's the type of code that goes into a library.
Additionally, small companies tend to sell to many users, and some of us are
warped enough to occasionally set the clock forward to 2012 or so, just to
see what happens. :-)
On the other hand, there's only one user of many government computer
systems, and those systems are in continuous use. If they don't test their
own software, nobody will.
On a related note, 7 years ago I came across an Ada relational database
which could handle most dates past the turn of the century, but had serious
problems with dates from March 2000 through February 2001. How many people
check for problems in that bit of logic? Don't assume that 01 Jan 2000 is
the only problematic date. I would also check around 29 Feb 2000, 01 Mar
2000 and 28 Feb 2001.
(The last two dates can be a problem due to day-of-week calculation
which uses a year running from March through February.)
The second paragraph is a rather interesting bit of institutional bigotry.
The Denver Post also runs radio ads for their weekend classified section,
referring to having plenty of jobs for "computer geeks."
I'll freely admit to calling myself a "geek," but the meaning of that term
as I use it is very different than the meaning implied by some hostile
copywriter. And it _is_ "hostile" when that's the only term used and it's
stretched to cover everything from a 13-year-old surfing the net to people
with 20 years experience and advanced degrees.
This article carries on that tone, with three paragraphs spent on this
"inside joke," but absolutely no space spent on the substantial effort that
has already gone into this effort, the lessons learned after the DOS "sign
change" in 1989, or the fact that many software professionals have been
fighting management for years over the need to start patching code _now_.
BTW, the "inside joke" offered wasn't the "Ship of Fools." (Everyone goes
on an extended cruise; the "fools" is a reference to the crucial role of the
fool or court jester in medieval Europe, roughly what we would have as a
"Devil's Advocate" today.) Instead it was a much more self-centered fantasy
about programmers retiring before 2000 (to avoid the frantic phone calls
from users?), and only when they realize it will affect their pension checks
do they decide to take action -- fixing the pension system software.
Overall, the tone of the article seems a lot like Christians taunting the
lions. The author admits there's a problem, a big problem, and that it has
the potential to harm him (with references to "income taxes, welfare,
employment records and the like.")
But rather than working towards a solution, he gratuitously insults the only
people who could help him.
Am I reading too much into this? Perhaps. But at the same time I've been
aware of this problem for years, and have played no small part in helping to
mitigate the problem. (I've found and reported several significant library
bugs for dates after 31 Dec 1999.) I find it hard to understand how this
reporter could spend several paragraphs on a joke, but not make a single
mention of the fact that many people have already been working on this
problem.
Hmmpf, he didn't even mention the '89 meltdown, which would seem to be a
good starting point since so many people had problems with it. It's a good
model of the problems we face in '00.
(For the curious, my project used DOS-style dates. A coworker and I both
used "unsigned [short] int" for all dates and our packages had no problems.
(The other guy also wrote the date package, fortunately.) It never occurred
to either of us that our coworkers might not have understood why the
"unsigned" was important, and one day their code suddenly started to fail.
Our product was very schizophrenic for a couple days, but we were able to
get fixed releases out quickly.)
Bear Giles
[email protected]
------------------------------
Date: Mon, 28 Aug 95 22:10:14 GMT
From:
[email protected] (Bear Giles)
Subject: Re: Risks of automatic newspaper publishing (Epstein, RISKS-17.30)
>a writer, who had made up the fake story for internal distribution,
The coverage in the local press suggests (to the sufficiently warped
mind) that this was a prank article for a female friend's birthday.
I guess the idea is that _she_ was the female in question, and the
fact that the reporter scheduled the following day off only seems to
strengthen this conjecture. ;-)
>accidentally put the article in the directory where stories to be in the
>next edition belong.
That's not hard to imagine; that's probably a short sequence which is
heavily used. He probably gave it as much thought as a "vi" user
gives to ":wq".
>Reaction by the newspaper readers has been
>mixed...some have been amused, while others thought it was "pornography".
That paper has a reputation for being laid back; the local coverage
made it clear that everyone involved (except possibly the Chief of
Police) was trying hard not to laugh too hard.
I would treat claims it was "pornographic" akin to claims "that in a
recent survey of 100 teenage Americans only 20% could identify Canada
on a map." (Or something similar.) It's possible, but it's much more
likely the people involved were having fun with a credulous reporter.
(You have to remember that this was _Aspen_.)
>In the meantime, the author of the particular piece is still working at the
>newspaper. The editor-in-chief did not disclose what punishment, if any,
>there would be.
He probably left that up to the reporter's girlfriend. I hope she
has a good sense of humor. (_We_ don't know the name of the woman...
but I expect her friends recognized clues woven into the story :-)
>The risk is that as newspaper production becomes more and more automated,
>there's less need for people to do reviews, and hence a greater risk of an
>error like this happening.
No, it's an example of the risks of an overly-serious workplace.
People _will_ play games with the computer system; in this case it's a
reporter writing bogus stories for a friend on the computer.
This is desirable because it helps the person develop new skills.
There are very few jobs (and none of them are very desirable) where
the skills you have on the first day are all you'll ever need. And
it's often not realistic to expect the person to have a sufficient
"mock up" available at home or elsewhere.
But the American workplace is increasingly "serious." You can get
into very real trouble for "screwing around," even if you can show that
most of your recent major advancements (instead of yet more regurgitation
of the same thing) directly followed such idle explorations.
And because you don't have a chance to learn how to safely work outside of
the main loop, if you do sneak in a bit of extracurricular fun you're much
more likely to accidentally put the lark into the main data stream. That
appears to be what happened here.
Bear Giles
[email protected]
------------------------------
Date: Mon, 28 Aug 95 17:53:41 -0700
From: Mark Seecof <
[email protected]>
Subject: Re: Risks of automatic newspaper publishing (Epstein, RISKS-17.30)
At the Los Angeles Times (where I work but which I DO NOT (generally)
represent at a policy level) we have several filters to avert the
publication of bogus news stories. Basically, most writers do not have
sufficient system authority to put stories directly into the paper
(although, of course, certain editors do... but they are trusted). The
organizational method of planning how to fill the space in each edition
provides the basis for a later sanity check on the material which is
actually sent to typesetting (cold) and pasted up.
However, we no longer employ proofreaders. Any glitch which isn't caught by
spell-check or a sharp-eyed editor will get into the paper and many typos
and editing mistakes do. And, as with so many systems, a privileged person
acting maliciously could put something inappropriate in (at least on an
inner page). Actually, we print more wrong stuff because our writers are
misinformed, or misunderstand their informants, or misrepresent something
out of ignorance than we ever do because of deliberate or inadvertent
sabotage. (We have printed errors, but never of any great magnitude. We
have never printed an improper front-page story for any computer- related
reasons.
One reason we haven't yet replaced our TANDEM-based integrated software
package timesharing-terminal system for news writing and editing is that we
would have to address many system reliability and security requirements in a
new system that most microcomputer-based client/server system vendors don't
handle well or sometimes at all.
We used to proofread display advertising matter, but we quit doing that a
couple of years ago. I myself once caught an ad with incorrect dates in it
when I walked through the composing room and glanced at the Travel section
being made up (we had been asked to run an ad which had run before. The
salesperson didn't realize that the dates--of cruise-ship sailings--were
"out of date" and needed to be "updated"). I spotted the anomaly and
alerted the composing people, who yanked the ad and called the salesperson.
We were able to get the correction in time to run the ad.
We do proofread classified (liner) ads--more to catch crooks (who attempt to
cheat the public, or sometime us) and deadbeats (who owe us money and try to
run more ads without paying us for the old ones), and to censor "offensive"
stuff (e.g., real-estate ads that suggest some kind of racial exclusivity)
than to find spelling errors. (Mind you, our classified salespeople don't
key in very many spelling errors.)
I might point out that we try pretty hard to keep advertisers who cheat the
public out of our pages. Such advertisers often cheat us too, plus we think
that readers who get cheated will be less likely to buy our paper and
patronize our other advertisers, and that in turn would hurt our business.
I like to think we would censor racist/sexist/whatever advertising no matter
what, but we are given extra incentive to do so by the law (which I believe
is a wicked, wrong law) that makes *the Times* liable to pay damages to
victims of advertisers who violate civil-rights laws, and sometimes other
laws, *even though the Times is not a party to the transaction*. (And
before any of you get too huffy about the benefits of 3rd-party liability as
a way of enlisting the otherwise indifferent in the war on -isms, realize
that we censor anything vaguely suspicious and be glad you're not trying to
rent out a house near a shopping center--'cause we may not let you advertise
"walking distance to shops" since that might imply you would discriminate
against cripples.)
Mark Seecof <
[email protected]>
Publishing Systems Department, Los Angeles Times
------------------------------
Date: Sat, 26 Aug 1995 15:31:13 -0500
From:
[email protected] (Peter da Silva)
Subject: Re: Dumpster diving on the Information Superhighway (Peters, 17.30)
Thomas Peters writes:
> It is easy to get credit card numbers through dumpster diving, shoulder
> surfing, dishonest retail employees, and telephone scams. All of these
> methods are much easier and simpler than cracking Netscape encryption
> with currently available technology.
Unfortunately for this argument, they're also a lot riskier. You have to
physically be in a location where the CC# is present for all but the
social engineering attacks like telephone scams, and unless you're cold
calling people and soliciting them (a low-return operation, and one unlikely
to generate high-limit numbers) you're dealing with people who have a valid
phone number for you.
------------------------------
Date: 9 August 1995 (LAST-MODIFIED)
From:
[email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <
[email protected]>
(Dennis Rears <
[email protected]>). UK subscribers please contact
<
[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
the newly automated <
[email protected]>, with first text line
SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
HELP
gives instructions on using the Majordomo listserver in other ways,
although not all are implemented for RISKS.
CONTRIBUTIONS: to
[email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.
RISKS can also be read on the web at URL
http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to
[email protected])
RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp
[email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail
[email protected] for info)
or visit the web wais URL
http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under
http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.
------------------------------
End of RISKS-FORUM Digest 17.31
************************
