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…
[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 <benry@telegraph.co.uk>. Abstracted by PGN.]
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]
BKEMLSEC.RVW 950127 "E-Mail Security", Bruce Schneier, 1995, 0-471-05318-X, U$24.95/C$32.50 %A Bruce Schneier schneier@counterpane.com %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 jdemarra@jwiley.com %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 ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
*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.
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
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 kschengi@interlog.com http://www.wimsey.com:80/tcp
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 jwhittle@amclg.safb.af.mil
> 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 tarl@tarl.net [home], tarl@east.sun.com [work]
Ashland, MA, USA http://tarl.net/tarl
[Rather similar comments also from
nick@cimio.co.uk (Nick Waterman),
Craig_Everhart@transarc.com,
"Rory O'Donnell" <rol@stadt.sp-media.de>,
Keith Price <price@raycharles.usc.edu>,
Mark.Kantrowitz@GLINDA.OZ.CS.CMU.EDU,
Marc Horowitz <marc@MIT.EDU>,
edward@igate1.HAC.COM (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]
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 gckaplan@ssl.berkeley.edu 1-510-643-5651
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
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 (kjahds@kjahds.com, CIS: 70705,126)
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 LISTSERV@UBVM.cc.buffalo.edu 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: david@arch.ping.dk
Tornskadestien 2, st. th. * Research * Tel.: + 45 38 33 03 30
DK-2400 Copenhagen NV, Denmark * Methods * Fax: + 45 38 33 88 80
Please report problems with the web pages to the maintainer