Subject: RISKS DIGEST 16.85

Subject: RISKS DIGEST 16.85
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Friday 24 February 1995 Volume 16 : Issue 85

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: [Note: ACM Computer Science Conference in Nashville NEXT WEEK]
Another police sting based on a freebie video offer (Clive D.W. Feather)
More Security Problems on the Internet (Edupage)
"E-Mail Security" by Schneier (Rob Slade)
*BUGS in Writing: [...] Debugging Your Prose*, by Lyn Dupre (Bob Donegan)
Re: CERT Advisory CA-95:04.NCSA.http.[...]vulnerability (Timothy Hunt)
Re: Perfect (?) Office Bug can cause harm (Keith Schengili-Roberts)
Re: Perfect (?) Office Bug can cause harm (Jerome Whittle)
Re: Sparc10 keyboards and resetting the CPU (Tarl Neustaedter)
Re: Major file corruptions (George C. Kaplan)
Re: Major file corruptions (George Buckner)
Re: Major file corruptions (Kenneth Albanowski)
Re: JUDGES-L (David Stodolsky)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Wed, 22 Feb 1995 07:33:49 +0000 (GMT)
From: "Clive D.W. Feather" <[email protected]>
Subject: Another police sting based on a freebie video offer

[Not really RISKS related, but interesting because stings
of this type seem to becoming a common practice. But soon
this will be happening on the information superhighway. PGN]

Drawn by invitations in the name of a fictitious market-research company, 31
``elusive criminals'' responded in person to a drawing for a year's free use
of telly facilities. After filling out questionnaires on their viewing
habits, they were then arrested. ``Operation Trick or Treat'' turned out to
be a Trick. (For you anagram freaks, the bogus company name, Mison Giewold,
is an anagram of the name of Detective Constable Simon Weigold, the officer
who organized the sting.) [Source: ``Prize draw proves winner for police"
-- by Nigel Bunyan, *The Electronic Telegraph*, 22 Feb 1995; inquiries to
its editor at <[email protected]>. Abstracted by PGN.]

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

Date: Thu, 23 Feb 1995 20:35:30 -0500
From: [email protected] (Edupage)
Subject: More Security Problems on the Internet (Edupage, 23 Feb 1995)

The Computer Emergency Response Team has issued a public warning on a
vulnerability in some 20 commonly used E-mail programs that run on Unix
operating systems. The advisory said the latest discovery could allow a
hacker to ``read any file on the system, overwrite or destroy files." The
ultimate solution to these recurrent security problems, says Purdue
University professor Eugene Spafford, is for consumers to demand better
security features from software manufacturers. In the absence of improved
software, "are we going to continue seeing problems? You bet." (Wall Street
Journal 2/23/95 B8)

[Spaf really said that's the ULTIMATE, eh?
That's as good as it can get?
Wow! We are really in for a bad time. PGN]

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

Date: Fri, 24 Feb 1995 13:27:32 EST
From: "Rob Slade, Social Convener to the Net" <[email protected]>
Subject: "E-Mail Security" by Schneier

BKEMLSEC.RVW 950127

"E-Mail Security", Bruce Schneier, 1995, 0-471-05318-X, U$24.95/C$32.50
%A Bruce Schneier [email protected]
%C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8
%D 1995
%G 0-471-05318-X
%I John Wiley & Sons, Inc.
%O U$24.95/C$32.50 416-236-4433 fax: 416-236-4448 800-CALL-WILEY
%O 212-850-6630 Fax: 212-850-6799 Fax: 908-302-2300 [email protected]
%P 365
%T "E-Mail Security"

This is the third work that I have seen on the PGP (Pretty Good Privacy)
text encryption and authentication system. (I understand that at least two
more are in the works.) It is also the first to truly present the general
concept of email security by covering the only other realistic option--the
Internet Privacy Enhanced Mail (PEM) standard and (Mark) Riordan's Internet
Privacy Enhanced Mail (RIPEM) implementation. The book divides roughly into
quarters discussing background, practical use, the PGP documentation, and
the PEM RFCs.

The work is considerably different, in style, to the Stallings
(BKPRTPRV.RVW) and Garfinkel (BKPGPGAR.RVW) efforts. Those books, while not
obtuse, were still written with a technical audience in mind. Schneier's
work, while definitely showing the expertise he demonstrated in "Applied
Encryptography" (BKAPCRYP.RVW), is clearly aimed at the general,
non-technical reader. (Interestingly, while he *does* tell you where to
find the RC4 algorithm posting, he *doesn't* mention the loophole recently
pointed out in the Clipper "Skipjack" algorithm.) The straightforward style
lulled me into thinking that chapter one was too long. It isn't: Schneier
makes the important point that, for it to be *truly* effective, encryption
must be used on *all* correspondence, even trivial items. So well crafted
is his argument that it would be difficult to reduce the chapter by so much
as a paragraph.

Schneier uses this argument to good effect in pointing out some of the major
deficiencies in the two systems. PGP is awkward to use, and PEM may use
incompatible algorithms. Surprisingly, he does not emphasize (though he does
mention) what is probably the major problem with each--the inability to use the
same system within and outside of the United States. The PGP fiasco is too
involved to get into here (see the Garfinkel work for details) and there is not
yet an "international" implementation of PEM (although there may soon be an
"authentication only" version available).

This won't help you design your own algorithm, but it is definitely for any
user of email, manager of communications systems, or student of privacy and
confidentiality.

copyright Robert M. Slade, 1995 BKEMLSEC.RVW 950127
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected], [email protected], Rob Slade at 1:153/733

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

Date: Wed, 22 Feb 1995 18:01:13 -0500 (EST)
From: Bob Donegan <[email protected]>
Subject: *BUGS in Writing: A Guide to Debugging Your Prose*, by Lyn Dupre

*BUGS in Writing: A Guide to Debugging Your Prose*, by Lyn Dupre
ISBN: 0-201-60019-6 $19.95 (price subject to change), 649 pp., paperback

[And WHAT, might you ask, does this have to do with RISKS? Well,
can you think of any bugs in computer systems that have resulted
from bugs in writing? We've seen quite a few in RISKS. And
besides, this is a terrific book. PGN]

*BUGS in Writing*, written with verve and wit, may be the first book on
writing that people read for sheer fun. Unlike traditional style manuals,
which present huge hierarchical rules bases (and which hardly make for
amusing reading), *BUGS* presents an alternative, intuitive way of looking
at written language that is based on the concept of ear: the ability to
hear, without analysis, whether a given work order, sentence, or term is
correct. *BUGS* explores problems that writers face, and explains how to
rid your prose of these bugs.

Designed for easy browsing, *BUGS* comprises 150 independent and easily
digestible segments, resembling a daily newspaper column and presented with
an unusual, appealing, inviting design. Dupre not only tells you about good
writing -- she also demonstrates it for you, conveying simple principles for
lucid writing by numerous, intriguing, and frequently hilarious examples
that are classified with the bugs system: Bad, Ugly, Good, or Splendid.

*BUGS* was developed for anyone who writes and who works with computers,
including computer and other scientists, students, professors, business
people, programmers, and technical writers. Rather than subjecting yourself
to the pain and tedium of wading through a reference book on English
grammar, you can pick up *BUGS*; you will immediately find yourself browsing
interesting and amusing material. While you are enjoying yourself, you will
be tuning your ear. As a result, you will write lucid prose that
communicates your ideas.

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

Date: Thu, 23 Feb 95 11:20:36 +0000
From: "Timothy Hunt [Assistant Unix Systems Manager]" <[email protected]>
Subject: Re: CERT Advisory CA-95:04.NCSA.http.daemon.for.unix.vulnerability

This is a warning about poor distribution of fixes for security holes.

In several locations on the 'net I have found the warning about the
security hole in NCSA httpd 1.3.

The fix they suggested was only to change the default string lengths, but
didn't include the patch to perform the functionality of strsubfirst().

While this will prevent any current attack programs from gaining access,
only a minor change would be necessary to attack the slightly modified
httpd (I think!).

This means there are probably a good many httpd daemons out there that are
still vulnerable, yet the administrators think they are now secure.

Timothy J. Hunt, The Institute of Cancer Research, Royal Marsden NHS Trust,
Downs Road, Sutton, Surrey, England SM2 5PT +44 (0)181 642 6011 x3312

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

Date: Wed, 22 Feb 95 15:21 WET
From: [email protected] (Keith Schengili-Roberts)
Subject: Re: Perfect (?) Office Bug can cause harm (Gillard, RISKS-16.83)

I read this submission to RISKS with some amusement. This particular
problem is not new to the WordPerfect portion of Novell's Perfect Office --
in fact WordPerfect is far from being the only culprit in leaving behind
stray ~*.tmp files. In the course of its operations, Windows and many
Windows applications often write files with a ~*.tmp filename to the \TEMP
directory listed in the AUTOEXEC.BAT file via the SET TEMP= command.
Windows normally removes these files automatically when you exit Windows.
If Windows crashes, or if you turn off your computer before exiting
gracefully from Windows, these files get left behind, and are not erased the
next time you start Windows. The accumulation of ~*.tmp files not only will
take up hard drive space, but can interfere with the operation of Windows
and Windows applications. Many a mysterious General Protection Fault I've
run across on other people's computers have been attributed to an
accumulation of ~*.tmp files on their hard drives.

The best thing to do is to erase these ~*.tmp files from your hard drive as
often as possible. Many people throw in a line within their AUTOEXEC.BAT
files which automatically go to the directory where ~*.tmp files are
stored, and delete the contents of that directory before launching Windows.
This must be done from DOS, rather than from within Windows, as Windows
does not take kindly to the attempted erasure of ~*.tmp files it is
currently using. If you are not sure where your ~*.tmp files are stored,
type SET from the DOS prompt, and the SET TEMP= will tell you which
directory to check. If no SET TEMP= line appears, the ~*.tmp files will
reside in your \WINDOWS directory.

My only criticism of WordPerfect (going back to version 5.1 for Windows to
the current 6.1 release) in this matter is that they consistently leave
behind more ~*.tmp files than most of the other Windows programs I have
used. I still prefer WordPerfect over most other wordprocessors however,
so I suffer with the problem and just erase the stray ~*.tmp files it
leaves behind.

Keith Schengili-Roberts, The Computer Paper, 99 Atlantic Avenue #408, Toronto,
Ontario M6K 3J8 CANADA [email protected] http://www.wimsey.com:80/tcp

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

Date: Wed, 22 Feb 95 08:19:00 cst
From: "Whittle, Jerome SMSgt" <[email protected]>
Subject: Re: Perfect (?) Office Bug can cause harm (Gillard, RISKS-16.83)

Unless Novell is really bad about it, I don't think Perfect Office
is the only guilty party. We use Microsoft Office here and have the
same problems. Actually I think that it is a Windows problem.

One of the things I do when I "tune-up" someone's computer is look for
temp files. I search using File Manager with a Search For: ~*.*. I
have literally found megs of temp files clogging up hard drives.

The user is usually to blame. The temp files should be deleted when the
user closes the application or shuts down Windows *properly*. If they
just turn off the power switch while Windows is still on the monitor,
temp files won't be deleted. In other words, tell them not to hit the
power switch until they see C:\. (Another problem with not shutting down
Windows properly is there will be lost clusters all over the place on the
hard drive. Using CHKDSK /F or SCANDISK, I've recovered up to 50 megs of
hard drive space!).

If they don't have a SET TEMP=C:\TEMP (or something similar) statement in
their AUTOEXEC.BAT, temp files will just dump all over the place. Also,
there better be a TEMP (or similar) directory or the same will happen.

Jerry Whittle, Belleville, Illinois, USA [email protected]

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

Date: Tue, 21 Feb 1995 23:56:08 -0500
From: [email protected] (Tarl Neustaedter)
Subject: Re: Sparc10 keyboards and resetting the CPU (Puchol, RISKS-16.83)

> It has happened to me several times now that I inadvertently knock the
> keyboard cable of the Sun SPARCstation 10 I work on these days. Most of the
> times, the result is a complete and instantaneous crash of the machine.

Actually, this is a feature.

I know, it doesn't sound like a feature. And there are more ways to
come to grief by this feature than just mentioned - most notable being the
well-intentioned conservationist who powers off an ASCII terminal being used
as a sun server console. The agonized screams from the users down the hall
usually alert the conservationist as to his impending fate. (See also:
http://pond.cso.uiuc.edu/ducky/docs/jimbo/raptor.html)

It doesn't actually cause a crash. Since time immemorial (long before
I started working with sun serial drivers), a BREAK condition on the
console line has been an attention signal telling a Sun to jump into
its prom. Unplugging a serial (async) line generates a BREAK condition.
Usually, you can recover by typing "go" after you plug the cable back in.

The reason it is a feature; Occasionally a user will do something he regrets
(certain programs which clobber the keyboard or simply won't exit should
not be run on the console), and the user needs some way to regain control of
his system. Unlike PCs, UNIX resents being powered off. It wants to be
politely shut down first. If you forget often enough, UNIX will take it's
revenge on you by eating your file system. Hence this escape into PROM.

On a normal ascii line, the only safe condition to detect is a "BREAK" -
everything else having been assigned functions by Gnu EMACS. On a keyboard,
where we aren't limited by ASCII, the "STOP-A" combination is normally used.
But "BREAK" serves the same purpose, and will sometimes work when STOP-A
won't (send me email if you want the grody details). Once you have gotten
back into the prom, you can "sync" the filesystems and reboot.

If you _really_ want to disable this functionality, you could find the
call to abort_sequence_enter() at the end of zsa_xsint in zs_async.c, and
NoOp it out. This keeps STOP-A/L1-A functionality (called from kbd.c) while
disabling the "BREAK" functionality. It helps to be handy with kadb.

But caveat emptor - Murphy's law guarantees that as soon as you disable
this functionality, within the next week you will desperately need it.

Tarl Neustaedter [email protected] [home], [email protected] [work]
Ashland, MA, USA http://tarl.net/tarl

[Rather similar comments also from
[email protected] (Nick Waterman),
[email protected],
"Rory O'Donnell" <[email protected]>,
Keith Price <[email protected]>,
[email protected],
Marc Horowitz <[email protected]>,
[email protected] (Ed Bruce),
and maybe others whose SUBJECT: field said only ``Re: RISKS-16.84" --
which means there is a chance that I will NEVER look at those messages,
unless perhaps I happen to do a search on some keyword. Note:
there is a WARNING to that effect in the INFO message. PGN]

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

Date: Fri, 24 Feb 1995 12:39:40 +0800
From: [email protected] (George C. Kaplan)
Subject: Re: Major file corruptions (Preston, RISKS-16.84)

Charles M. Preston's story of corrupted files (in RISKS-16.84) sounds like a
situation I once saw that was traced to a flaky disk controller. Sometimes
one or more bits would be cleared somewhere in the file. Since it was the
"0x20" bit, we first noticed it when random scattered letters were
capitalized in text files. Sometime later, presumably after buffers had
been flushed, the affected files would be back to normal.

The service tech didn't quite believe us, but he replaced the disk controller
board, and the problem went away.

George C. Kaplan [email protected] 1-510-643-5651

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

Date: Fri, 24 Feb 95 15:45 EST
From: George Buckner <[email protected]>
Subject: Re: Major file corruptions

I've discovered a tendency for PKUNZIP to report corrupt files when I run it
from a DOS shell while Windows is running. This problem goes away if I
close Windows first. (No this isn't a fix or an explanation, but my
temporary work-around).

George Buckner

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

Date: Fri, 24 Feb 1995 15:49:27 -0500 (EST)
From: Kenneth Albanowski <[email protected]>
Subject: Re: Major file corruptions

Charles Preston asks "what type of problem, other than malicious
programming, could cause these symptoms?", in regards to an on-line service
occasionally serving up damaged files.

The possible reasons for such behaviour are numerous, and it aids no-one to
call up the specter of a rouge programmer or "hacker", if such a thing is
not known to be true. This is a risk that is now being run by everyone
providing an electronic service: an accusal of being "hacked", or of
"downloading the users hard disk in secret", or of "damaging files for
unknown purposes", (just to name a few,) carries a large weight in the
press, and is potentially difficult to fight.

I believe Charles is talking about the CompuServe Information Service, which
I have heard some small comments about infrequent damage to downloaded
files. The behaviour is supposed to be quite uncommon, and goes away on a
repeat of the transfer. Of course, Charles could be talking about any large
service that provides files for download. Anything from a damaged disk
drive to a fluky controller card to a out-of-tolerance CPU to a buggy
program could cause these problems, and I know of no company that is immune
to such things.

Lastly, yes, since the file-transfer checksums matched, having a secondary
checksum (in this case, actually a CRC provided by PKZIP) would certainly
prove useful. That's why PKZIP does it, and why CRCs are in common use.
This also points out the risk of not verifying data integrity on all levels.
Presumably a CRC check used at some stage in the service's computer would
have detected the problem earlier.

Kenneth Albanowski ([email protected], CIS: 70705,126)

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

Date: Wed, 22 Feb 95 19:32:08 +0100 (CET)
From: [email protected] (David Stodolsky)
Subject: Re: JUDGES-L (da Silva, RISKS-16.83 on Stodolsky, RISKS-16.82)

Looks like Peter da Silva was confused by the "Cancel Messages:
Frequently Asked Questions Part 2" post, a forgery meant as a joke.
The List has released a single informational post, a single time. It
was developed with contributions from leading Usenet administrators,
some of whom have chosen to remain anonymous. When the latest version
was approved, via a consensus decision making process, there were
about a dozen leading administrators subscribed, and under the rules,
anyone of them could have blocked its release, or tried to, thus
precipitating a vote. This did not occur. It was a consensus document.
(The forgery was, unfortunately, taken seriously by all too many,
including the Italian EFF. This perhaps is an indication of the need
for informational posts on this topic.) The authentic document starts
with a summary:

Cancel Messages: Frequently Asked Questions (FAQ). Ver. 2.0
Summary:

You can protect your reputation as a information source by cancelling
articles posted under your name as soon as you discover that they are
erroneous.

Cancelling other's articles, however, can expose you, your site, and the
Net as a whole, to serious threats. The sender should be notified when
articles need to be cancelled.

Disputes or doubtful cases can be directed to the Judges' List for
resolution.

The List is open to anyone who agrees to follow the rules adopted through
the List's consensus decision making process. The List is not confidential,
that is, it can be located by a LISTSERV search. It is also open to review
by the public. A review command to [email protected] will yield
the settings and membership of the List. This will show, among other things,
that anyone may send mail directly to the List: There is no editor who must
approve messages. Since the List now offers confidential dispute resolution,
the continued dissemination of messages via mail-to-news gateways, etc. was
deemed inappropriate. This question, however, continues to be debated.

Information about the NetNews Judges (TM) List appeared in the _New
Scientist_ magazine at the end of last year. It is also discussed
in the most recent issue of _Matrix News_. I was also interviewed
recently by a reporter from _The Chronicle of Higher Education_ about
the List.

David S. Stodolsky, PhD * Social * Internet: [email protected]
Tornskadestien 2, st. th. * Research * Tel.: + 45 38 33 03 30
DK-2400 Copenhagen NV, Denmark * Methods * Fax: + 45 38 33 88 80

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

Date: 6 February 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
<[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

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>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, 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 16.85
************************