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…
In an astonishing gaffe, government intelligence experts writing for the Moynihan Commission's recent "Report . . . on Protecting and Reducing Government Secrecy" reveal they've been hooked on one of the Internet's ubiquitous e-mail computer virus hoaxes known as "Penpal Greetings"! In a boldly displayed boxed-out quote in a _lengthy_ part of the report entitled "Information Age Insecurity," the authors proclaim: "Friendly Greetings? "One company whose officials met with the Commission warned its employees against reading an e-mail entitled Penpal Greetings. Although the message appeared to be a friendly letter, it contained a virus that could infect the hard drive and destroy all data present. The virus was self-replicating, which meant that once the message was read, it would automatically forward itself to any e-mail address stored in the recipients in-box." The Penpal joke is one in half-a-dozen or so permutations spun off the well-known GoodTimes e-mail virus hoax. Variations on GoodTimes have appeared at a steady rate over the past couple years. The report's authors come from what is known as "the Moynihan commission," a group of heavy Congressional and intelligence agency hitters tasked with critiquing and assessing the Byzantine maze of classification and secrecy regulation currently embraced by the U.S. government. Among the commission's members are its chairman, Daniel Moynihan; vice-chairman Larry Combest, Jesse Helms, ex-CIA director John Deutch and Martin Faga, now at a MITRE Corporation facility in McLean, Virginia, but formerly a head of the super-secret, spy satellite-flying National Reconnaissance Office. The part of the report dealing with "Information Age Insecurity" merits much more comment. But in light of the report's contamination by the Penpal virus hoax, two paragraphs from the March 4 treatise become unintentionally hilarious: "Traditionally, computer security focuses on containing the effects of malicious users or malicious programs. As programs become more complex, an additional threat arises: _malicious data_ [Crypt Newsletter emphasis added] . . . In general, the outlook is depressing: as the economic incentives increase, these vulnerabilities are likely to be exploited more frequently. ---W. Olin Sibert, 19th National Information Systems Security Conference (October 1996)" And, "Inspector General offices, with few exceptions, lack the personnel, skills, and resources to address and oversee information systems security within their respective agencies. The President cannot turn to an Information General and ask how U.S. investments in information technology are being protected from the latest viruses, terrorists, or hackers." Got that right, sirs. - - - - - - - Notes: Other authors of the commission report include Maurice Sonnenberg, a member of the President's Foreign Intelligence Advisory Board; John Podesta, a White House Deputy Chief of Staff and formerly a visiting professor at Georgetown University's Cyberlaw Center; Ellen Hume, a former reporter for the Wall Street Journal; and Alison Fortier, a former National Security Council staffer and current Rockwell International employee. Unsurprisingly, much of the report appears to be written by staff members of the commission chairmen. An initial phone call to the commission was answered by a staffer who declined to name the author of the part of the report carrying the Penpal hoax. The staffer did, however, mention he would forward the information to the author. Contact for the Moynihan Secrecy Commission: 202-776-8727. An electronic copy of the Moynihan Commission report is mirrored on the Federation of American Scientists' Website (http://www.fas.org). George Smith Crypt Newsletter http://www.soci.niu.edu/~crypt
>From "The Advocate" (Baton Rouge, LA), 4/3/97, page 1A (front page): Glitch in jail system opens doors, again (Associated Press) ASHLAND — All the inmate cell doors at the Terrebonne Parish Jail opened automatically late Tuesday night because of a computer malfunction. It was the third time in the past two months that computer problems caused a security breach at the prison, located about seven miles south of Houma, said Terrebonne Parish Sheriff Jerry Larpenter. All of the jail's 464 inmates stayed in their cells, Larpenter said. Larpenter said that he got the call about 9 P.M. "I didn't appreciate it. I was hoping it was not an April Fool's joke," Larpenter said. "I don't like being on the opposite end of a joke." What a great attitude!?! He'd prefer a malfunction that opens all of the cell doors as opposed to being the subject of an April Fool's prank. I've always complained about the stereotypical Southern law enforcement officer depicted in movies ... maybe I'll stop complaining. I guess the April Fool's prank was on the inmates ... Door's open, you can leave. Oops! Sorry! Computer malfunction! Get back in your cell. Darrell Pitzer <DRPITZER@ACM.ORG>
It seems that the ghost of the FDIV bug lives on in Excel spreadsheets created using Pentiums affected by the problem. I finally got rid of my Intel Pentium computer with the FDIV bug. Last night, while checking out my new Pentium Pro computer with Microsoft Excel 97 I decided to open up the spreadsheet which demonstrates the Pentium Floating Point divide bug. I was surprised to find that that the calculation of: 4195835 - (4195835/3145727)*3145727 within the spreadsheet still showed the answer 512 instead of zero. I pressed the recalculate key (F9) to no avail. So then, I retyped the formulas in neighboring cells. Where I had retyped the formulas the answer(s) were correct, but the same formulas that had been saved from when I had done the calculation on the defective Pentium still showed the wrong answer! In other words, here, on the same spreadsheet was the same problem with two different answers, one correct and one incorrect. The only way I could find to "correct" the incorrect answers was to retype the formulas over the originals. It seems to me that this "ghost" could represent some risk since it is logical to assume that if you're no longer using a defective Pentium, you needn't be concerned about wrong answers on the spreadsheets you've moved to a new machine. This obviously is not so. I've sent in a bug report to Microsoft as of this morning. Frank Solomon, University of Kentucky (606)257-2133 sysfrank@pop.uky.edu http://www.uky.edu/~sysfrank
Anyone interested in a "war story" about how errors are introduced into the relatively simple problem of releasing new versions of a library should read http://17.126.23.20/dev/technotes/tn/tn1095.html . It would make an interesting exercise in a software engineering course to describe how a process could be developed which would have prevented some of these errors from occurring. [I hope this URL sticks around. Much as I hate to put possibly ephemeral URLs into the long-term archives, this item is worth reading but is to complex and interesting to summarize briefly. PGN]
The original posting about automatic cancellation of cards may have been in error - see attached posting. Another poster said the building from which the computer was stolen looks like a dilapidated shack and not really a good place to store sensitive data or easily-stolen computers. Al Stangenberger, Dept. of Env. Sci., Policy, & Mgt., Univ. of California at Berkeley, Berkeley, CA 94720-3114 (510) 642-4424 forags@nature.berkeley.edu - - - - From: mikel@dosbears.com (Mike Lipsie) Newsgroups: ba.transportation,misc.transport.urban-transit Subject: Re: CalTrain computer stolen — rider alert! Date: Thu, 03 Apr 1997 03:44:23 GMT [Referring to ab@nt.com (Adrian Brandt), included in RISKS-19.02] As I read the letter, CalTrain had told the credit-card people that the numbers were in a computer that was stolen and expected the cards to be cancelled. I think the credit-card companies are saying, "Again? Usually they are stealing the computer and not the data. We'll wait and cancel if necessary." [...] However, this is the second time within a year that a computer with my credit-card number on it has been stolen. I will be extra alert but I don't really expect anything to happen. And, since I have a half-dozen (or so) auto-pay arrangements, I really hope that is the case. Mike Lipsie mikel@dosbears.com
Emergency! Crisis in the Cockpit
by Stanley Stewart
TAB Books, 1991
264 pages, illustrated w/bibliography
ISBN: 0-8306-6499-8
I just finished _Emergency! Crisis in the Cockpit_. Apart from the horrible
title, this is a rather interesting book by Stanley Stewart, a BA 747
captain. He deals with in-flight emergencies in which death was *avoided*.
Imagine that. :-) He thoroughly describes nine incidents/accidents:
1. Pacific Search. Deals with a 1978 incident involving an Air New Zealand
DC-10 assisting in the search for a lost GA pilot over the Pacific.
2. The Bermuda Triangle. EAL L-1011 vs. no O-rings on its chip detectors
resulting in shut down of all three engines.
3. To Take-off or Not to Take-off. The Pan Am 747 collision with runway
lighting on takeoff resulting in the loss of three of four hydraulic
systems.
4. The Windsor Incident. The AAL DC-10 floor collapse.
5. Don't be Fuelish. The Air Canada 767 fuel starvation incident.
6. The Blackest Day. Black September, focusing on the hijacking of the PAA
747.
7. Ice Cool. Ryan Aleutian Airlines vs. frozen fuel pumps. All-engine
failure.
8. Roll out the Barrel. The China Airlines 747 flip-over.
9. Strange Encounter. British Airways 747 vs. a volcanic ash cloud. Loss
of all engines.
Each story is based on interviews with the crews and on external printed
sources. Each is presented verbatim, warts and all. If crews made dumb-ass
mistakes handling the emergency, they are presented verbatim as part of the
decision flow, without comment.
Although the book is designed for a general audience, the stories are told
from the pilot's perspective (not a single "Little Johnnie was waiting in
Cleveland for the liver transplant in the cooler in the back." :-)) and
sometimes gets fairly technical.
I enjoyed it. Recommended.
In RISKS-19.02 there are a number of articles concerning `spam'. There is a Risk in the use of this (Monty Python derived) term in discussion of this issue, as it is not precisely defined. If we are to start using measures against these communications, we should, in my opinion, start using a more precise term. `Spam' is used to cover ECP (Excessive cross posting) and EMP (Excessive multiple posting) on Usenet, UCE (Unsolicited commercial e-mail) or occasionally any unwelcome unsolicited e-mail. ECP (and to a lesser extent EMP) can be detected and removed automatically, and a number of precise metrics have been developed and generally (although not universally) accepted as to when this is appropriate. The use of the term `spam' for electronic mail is less well defined. It is generally assumed to include UCE, but is often used to refer to any unwanted unsolicited mail. As to my preferred anti-UCE method (about which there seems to have been little discussion), I am alpha-testing an implementation of aliases as time-expiring Capabilities, the expiry time usually set to around a fortnight. Usenet is in essence, a transitory medium, soon the capability to mail me shall be just as transitory. Whilst any freshly cropped aliases will still work, it makes the compilation of UCE lists difficult, (I also need only stop posting for a week or so and I will receive _no_ UCE, until I start posting again). Whilst those who regularly post to Usenet will still receive a reasonable amount of UCE, many people who post infrequently have none the less found themselves on a UCE list, the use of time expiring aliases prevents this having long-term consequences. A well thought out implementation can even allow the filtering to be performed by a trusted third party, and the creation of aliases on machines with transient connectivity. I have tried, in developing this, to minimise the work which needs to be done by someone who is genuinely replying to a message, as pointed out [Wayne Mesard in RISKS-17.02] an inconsideration and potential stumbling block for new users, whilst providing security against address unmungers. The compromise means for a short time after posting a few UCE get through. I'd welcome comments on the potential risks and benefits due to this technique before I release my (free) implementation for beta-testing. Dan Sheppard.
Re: aste-RISKS (Warning to MSIE users), RISKS 18.94
> [Ah, yes, by all means, avoid the aste-RISKS of being spammed! ... PGN]
I am guessing that mass-e-mailers have trolled the RISKS archives. Some
recent spams I have received:
To: UArtison@aol.com
Date: Thu, 13 Mar 97 01:32:05 EST
Subject: *** 8 MILLION E-MAIL ADDRESSES ***
To: Friend@public.com
Date: Sun, 23 Mar 97 22:09:38 EST
Subject: MASS E-MAIL GETS $TRAFFIC$ TO YOUR WEBSIGHT---$SALES$---FOR
YOUR BUSINESS
To: box18@mediabrokers.cobracomm.com
Date: Mon, 24 Mar 97 11:03:43 EST
Subject: Purchase Corporate MKTG lists, SIC's, Area Codes, etc.
Any other contributors so blessed?
Given this influx, I like the idea of the mangled (yet still human-readable)
e-mail addresses. I think the placement of the 'aste-RISKS' is important,
however.
I suggest putting the aste-RISKS within the top level domain (i.e. .Xca,
.Xcom) rather than on the user id. This puts the load on the spammers' DNS,
rather than on the receiver's internet provider. No point having my ISP
waste cycles looking up bogus accounts.
Or maybe we could ROT-13 e-mail addresses? benz@havkt.hop.pn
A RISK of aste-RISKS technology? Everyone will start using the same method,
and spammers will simply know to replace .Xcom with .com. So I guess you
should all ignore my advice and do your own thing...
Wbua Benz, benz@havkt.hop.pn, uggc://jjj.benz.pbz
X marks the spam - remove the X from my return e-mail address.
Wayne Mesard mentions that a trend on the Internet is to change one's e-mail address on outgoing news and e-mail so it is not valid in some obvious way, and request that the recipient make the appropriate changes to make this e-mail address valid. He forgot one risk in his list: when you send out e-mail like this, you won't get any indication if your e-mail cannot be delivered, because the automatic systems that notify you that your mail could not be delivered will not be able to send you that notification. I've noticed this problem in particular with some of my customers who use a Windows newsreader called Free Agent; they use it for mail as well, but they can't have separate e-mail and news From: addresses, so it's inconvenient for them to use a modified address for news, but not for mail. Curt Sampson cjs@portal.ca Internet Portal Services, Inc. Vancouver, BC (604) 257-9400 Info at http://www.portal.ca/
The cost of this is not to be underestimated. For most people, the chief
problem with spam is not that it consumes a significant amount of any
tangible resource (money, network bandwidth, disk space). The cost is in
the time spent deleting and/or complaining about the spam, and in the
annoyance factor, both of which harm productivity. Spam is problematic
because it shifts the cost (of targeting one's message) from the producer to
the consumer. Similarly, spam-proofing one's e-mail address is problematic
because it shifts the cost of communication from the sender to the
recipient.
Another risk is that an e-mail address so ``spam-proofed'' may inadvertently
identify some innocent third party. (This has been discussed here before,
in the context of deliberately forged messages and accidentally
misconfigured message clients.) Posters who change the domain name of their
addresses to `nowhere.com' may be surprised to learn that nowhere.com is a
real domain, but the nowhere.com users or postmasters who receive responses
to their mail may not be amused.
>- False security 2: In the ever-escalating spam arms race, it won't be
> long before spammers' address-gathering software is modified to
> unmunged munged "From:" lines. [...]
I will discuss one of these techniques, if only because most people do not
seem to believe me when I say that I have actually witnessed it.
Most e-mail spam does not actually list the recipients of the spam in its
headers, but some spams do. I received such a message a few weeks ago, and
in the process of examining the headers in order to complain, I came across
the most curious pair of addresses. They were of a format similar to this:
jqdoe@removethistoemailme@somewhere.com
jqdoe@thistoemailme@somewhere.com
Now, it's entirely possible that the user responsible for these addresses
actually did use both of them at one time or another, but it seems awfully
unlikely: the phrase ``thistoemailme'' does not clearly indicate an action
for the recipient to take. More plausible is that the spammer responsible
for this message filtered his list of addresses through a program which
removes strings like `remove', `spam', or `nospam' (and then includes both
the filtered and unfiltered addresses just to be on the safe side).
It shouldn't be long before someone teaches them about regular expressions.
<> The risk of false and malicious blacklisting of non-spammers. (Riddle) Dan> This is a serious problem. A step towards solving it would be [...] This is unnecessarily complex. The NoCeM effort (see http://www.cm.org/ for details) has simply, and effectively, dealt with the spam problem for usenet. Efforts are underway to adapt this to e-mail. NoCeM works this way: * Someone takes it upon himself to watch for spam in a newsgroup (or groups). * When spam does appear, that someone posts a "NoCeM" message to news:alt.nocem.misc and/or news:news.admin.net-abuse.misc, PGP signed. * Users who want to benefit from the filters have clients that, when they grab news, look in news:alt.nocem.misc (and potentially other places) for NoCeM messages. The client verifies the signatures, and if it's signed by someone the client agrees to listen to, the message won't be shown to the user at all. * Clients are also available to work with news servers, to NoCeM messages on a site-wide basis. (I believe that these actually cancel the NoCeM'd messages on the site.) This is nice, because it uses what's already there (news), and allows the user (or admin, depending on the model) to select which users' NoCeMs he honors. Either you trust someone's judgement and honor their NoCeMs, or you don't, and they're completely ignored. Dan> Unfortunately, doing this would subject whoever did it to a suit Dan> by spammers who didn't want to be blocked. Superfluous lawsuits are threatened all the time... few have the resources of CyberPromo to actually be stupid enough to try any of this. (It's another thing about NoCeM...it doesn't kill the messages, it just is another post, that certain clients deal with behind the scenes. :-) Matt Curtin Chief Scientist Megasoft, Inc. cmcurtin@research.megasoft.com http://www.research.megasoft.com/people/cmcurtin/
Instead of having a central repository of spam, why not use a distributed spam-control system analogous to NoCeMs for Usenet news? Anyone could then issue digitally-signed spam-block notifications, but an individual user would configure their system to only apply notices that came from cancellers they trusted. An Alpha version of NoCeM for e-mail already exists, at <http://www.novia.net/~doumakes/abuse/>. Some advantages of this system are: o It thwarts malicious individuals or organizations attempting to systematically censor e-mail. Unless the user lists them as trusted cancellers, their notices will be ignored. o A 'spotcheck' mode would allow users to occasionally receive an otherwise cancelled e-mail, to ensure that an otherwise trusted canceller hasn't stepped over the line between spam-blocking and censorship. o There is no risk of some central database being compromised by spammers or censors. o Users receive more timely warnings of new spam, without needing to periodically check and download a spam-list. o The spammers have no-one to sue for freedom-of-speech violations. While I'm not a lawyer, I can't see any way to sue someone for merely suggesting that a spammer's mail isn't worth reading. > > The risk of harm to innocent bystanders who happen to share hostnames, > > ISPs, or other characteristics with targeted spammers. > > This is not a risk. This is a benefit. [...] I can't see that this is a benefit. Changing your ISP is hardly a trivial task - you have to notify all of your correspondents of your new e-mail address, archive any web pages you may have stored at your ISP, reconfigure your internal network if you were using a Class C subnet, etc. It's grossly unfair to punish legitimate users because they were unfortunate enough to have some Canter and Siegal wanna-be set up shop on their ISP. Ted Wong Information Technology Section Mann Library, Cornell University <tmw5@cornell.edu>
> [...] they will take their business elsewhere. Easy to say from a university or company account. In the real world, nobody wants to change addresses and notify all of their correspondents, especially if it means losing an established presence that may have been widely disseminated to =potential= correspondents (not to mention reprinting stationary and business cards). And why should the multitude suffer this inconvenience, expense, and loss of communication, for the activities of the few? Spam is the biggest single argument for usage charges. As long as it's cheap to set up a new address and free to abuse it, there's no reason for the spammers to cut down on e-mailing spam and freeloading on other people's processors and comm lines. The fact that spam can be sent from a domain shared by many legitimate users, and that even new addresses may be reused after the spammer changes away, means that abusers are hiding among the innocent like hostage-taking terrorists - hyperbole, perhaps, but congruent in style if not in magnitude. The goal of any anti-spam approach should be to block, slow, or encumber transmission as close to the source as possible. Yet legitimate cases are always at risk; limiting the cc: lines, for example, could inconvenience clubs or companies almost as much as it slows the spammers. As in any police-power or security effort, the problem is how much freedom the average innocent person is prepared to give up so that the abuser can be blocked. -harlan
> The original spamming host is going to show up somewhere in the Received: > line, [...] Note that if you are fortunate enough to have Received: lines to work from (the most recent spam I received had none at all, either because the relay host was defective or because it really was sent directly to my mailhost) you still have a challenge, because the spammer can insert one or more bogus Received lines in the initial message, so the one added by the first relay host will be buried in the middle. By the way, it does not seem practical to me to block all mail-relay sites that don't add Received lines. How would you generate such a list? What incentive would you provide to such a site to change their software? Dan Franklin
Any method of auto-blocking spam will create a serious problem for anyone who later acquire the spammers' discarded domain names. Spammers are registering lots of domain names and faking many to evade anti-spam and cancel bots and to hide from their enemies as well as the public at large. Once they are done with the domain names and they--the registered names--become available again, the next organization to acquire the name will find their mail bouncing or disappearing into /dev/null somewhere and perhaps harassed by bots and hostile spam-haters which do not know that the domain name has changed hands. The unfortunate victims of such acts may not even be able to escape them by merely changing their domain name, either. Who is going to removed dead spammer domains from the anti- spam and cancel bots' records and make sure that everyone knows about it? onymouse@hypatia.com | I've only one thing to Send NO spam | say to spammers: "47USC227". [Many thanks to an onymouse contributor (J DeBert), who acted as a guest moderator for this topic. PGN]
Please report problems with the web pages to the maintainer