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…
>From *Computer Weekly* 7 Jun 2001, on the back page. ... a tale of cutting edge IT going off the rails. It reads, "I had an interesting journey home from London last night. I was onboard a new 100% computer-controlled train. In the middle of the Chester countryside, the train ground to a halt. The automated station-announcement system then ran through its program of station announcements in quick succession until it said the final destination." "It then attempted to open the doors (in the middle of nowhere). The guard ran to the driver's cab. The driver and the guard then ran through the carriages muttering that the computer had gone berserk and was telling them that the rear of the train was on fire. After checking, the driver, in a state of mild panic ran back to the cab, turned off all the engines, cut off all the power (leaving us in pitch darkness), and yes, you've guessed it, waited the customary - 10 seconds and rebooted the train. I wonder if anyone can confirm this wonderful story. The risks are self-evident. SCS Global Services Internet/Intranet Operations, GlaxoSmithKline, Medicines Research Centre, Gunnels Wood Road, Stevenage SG1 2NY UK
cf. http://www.chron.com/cs/CDA/story.hts/metropolitan/936841 Though not mentioned in this article from the *Houston Chronicle*, NPR reported (via KUHF?) that the elevator detected an emergency situation and automatically attempted to move to the ground floor. While that's often a good idea in case of a fire, in a flood it's the *worst* way to respond and, in this case, tragically lethal. [I was in an elevator at BBN in Rosslyn VA once when the control computer crashed. The elevator very slowly worked its way to the TOP floor, which might seem to make sense — *except* in a fire. Thus, we need an intelligent system that figures out which way to go, and therein lie even more risks — especially in a fire that results from a short caused by a flood. PGN]
The Pulse EFT network's main and backup power systems in Houston were flooded by Tropical Storm Allison, disabling their 22-state ATM network. "PULSE Enacts Disaster Recovery Program Early Saturday morning, the PULSE electronic funds transfer system experienced a major disruption of both our primary power source and our emergency back-up supply system, as a result of unprecedented flooding in Houston. A disaster recovery program has been instituted and efforts are underway to resume operations at a remote processing center located in Dallas. Until technical connections in the system can be restored, disruption of ATM and point-of-sale services at some locations will be experienced. PULSE has a proud record of 99.99% availability and we regret any inconvenience to our financial institutions, merchants, processors and cardholders that this extraordinary event may have caused. [...] http://www.pulse-eft.com/
In the Kyllo case, the Supreme Court ruled 5 to 4 that using an Agema 210 thermal-imaging device to scan for unusual heat sources in someone's house (i.e., searching for marijuana growing activities) is unlawful search if carried out without a warrant, violating the Fourth Amendment. http://www.supremecourtus.gov/opinions/00slipopinion.html http://supct.law.cornell.edu/supct/html/99-8508.ZS.html http://www.wired.com/news/politics/0,1283,44444,00.html
http://www.utm.edu/research/primes/curios/48565...29443.html One of the strangest consequences of the DMCA is that it would seem to outlaw possession of certain integers. The above URL gives the decimal form of a prime number whose HEX form just happens to be the gzip-ed C source code for DeCSS (which breaks the DVD Movie encryption — see RISKS-21.37). This observation is due to Phil Carmody. [Thanks to Mark Brader for the Subject: line!]
http://www.cnn.com/2001/TECH/ptech/06/08/pentagon.computers.ap/index.html The aggregation, inference, and sensitive-unclassified stuff is ubiquitous and often damning. This could be a harbinger of future RISKS stories.
I'm the maintainer of a free-software application called sitescooper, which
reformats Web sites for viewing on PDAs. When I started writing sitescooper
a few years ago, I hosted it on my ISP at
http://www.clubi.ie/~jmason/software/sitescooper/ .
Since this URL was quite cumbersome (especially when read on a PDA screen!)
I also set up a forwarding URL with a domain called "tsx.org", which offered
free URL forwarding. At that stage, tsx.org was a reasonably reputable
URL-forwarding service.
Since then, sitescooper has grown in popularity, and has moved to the
easier-to-remember sitescooper.org domain. I left the tsx.org forwarding in
place, updated to its new address, to catch old links and avoid link-rot,
and forgot about it.
This morning I received a mail from a potential user, who'd decided to
download sitescooper and take a look. The mail stated:
I'm writing about your Web site. [...]
If you are aware of the way your site behaves then you should just
close up shop and leave the Web because no contribution to software
development is worth the hassle your site causes.
If not, then I apologize for the above and I'll describe it for you.
If your site: sitescooper.tsx.org is opened using a script-enabled
browser (e.g., IE or NS), from a windows platform, it proceeds to
plaster the screen with windows full of trashy ads that CANNOT be
deleted. The windows have no controls and right-clicking the taskbar
icons is disabled. THE ONLY WAY to delete this trash is to bring up
the Task Manager via ctrl-alt-del, and kill the processes. NO WEBSITE
SHOULD BE THIS INVASIVE.
This is blatant abuse of the trust a user puts in you when they click
a link to your site. Hopefully, you're not involved in it and it's
being done by tsx - In which case I STRONGLY advise you to dump them
as fast as possible and find a new Web host.
I surfed over to sitescooper.tsx.org and took a look. Sure enough, it
popped up 5 windows - 1 with no frame masquerading as a Windows alert,
asking if I want to visit the BEST ADULT SITES AROUND, 2 full-screen
unclosable windows, 1 normal(ish) ad window with a normal window frame, and
(finally) the page I *wanted* to go to.
Gah. Needless to say, sitescooper.tsx.org is now no more. I'd prefer if
people hit a 404, and were forced to search Google, than run into this.
The risk? There ain't no such thing as a free lunch, I guess. I'd assumed
that the forwarding system would offer a consistent quality of service over
several years; instead, in my opinion, they took advantage of their
situation to increase their ad revenues at the expense of their users.
First came SPAM, with its authors finding more and more sophisticated methods of hiding themselves from their victims so they could send out massive amounts of advertising without fear of retribution. Then came pop-up window ads. These are bad enough, but now a company, www.fastclick.com, has come up with a way to sneak these pop-up windows onto your screen without you knowing where they came from. Worse, established corporations such as The NY Times (www.nytimes.com), AltaVista (www.altavista.com), and Epinions (www.epinions.com) are using the technology. The trick involves a timer, a cookie, and a pop-up window that quickly hides itself *behind* your browser windows. This usually happens too fast for your computer to render the window on your display, so you see nothing. You don't know when the ad will appear, and you won't see it until you close all of your browser windows. By then, you have opened a few more windows and browsed to other Web sites. This keeps you from knowing which Web site spawned the window in the first place. I only know about the above three corporations because I was lucky enough to catch the window popping up when I first opened my browser to these sites, or because it was the only site I went to. I caught a glimpse of "fastclick.net" in the status bar, and it all fell into place. The only solution is to turn JavaScript off completely. If you don't want to do this, then add the offending sites to your "Restricted Sites" list. I have sent a complaint to these corporations as well, letting them know that I don't appreciate this "sneaky" advertising, and have disabled these ads.
Greetings. The manufacturers of e-mail filtering and blocking systems continue to claim that their products have vastly improved over time --that the incidents of false negatives and false positives are greatly reduced from earlier versions. Much empirical evidence has continued in general to contradict these assertions, and here's yet another example of what happens in the real world as these systems are actually configured by users. My most recent PRIVACY Forum Digest was blocked by the popular "ScanMail" product as configured within at least one site. I only learned about this since the particular configuration was in a "quarantine for review" mode that sent out a warning. Other sites may be configured to simply delete flagged messages without such a reply to the sender. What was it about the PRIVACY Forum Digest that aroused ScanMail's ire? In the nine years since I originated the Digest, each issue has included a "quote of the day"--which usually is an interesting or amusing quote from a feature film. In the case of the most recent Digest (http://www.vortex.com/privacy/priv.10.04) I chose a quote from Peter Sellers' 1968 classic "I Love You, Alice B. Toklas!" Ah hah! The phrase "I Love You" appeared in the text of the message. It must be a virus! Or perhaps a spam? Indeed, the Digest was blocked via ScanMail's "ILOVEYOU" policy! This was done even though the message was not encoded in any way and was not an attachment. It was just simple, plain, ordinary, ASCII text, with the "offending" phrase well down within the message (not in the header). Presumably, ScanMail at various sites will be blocking *this* issue of RISKS because (horrors!) the forbidden phrase "I Love You" appears in this message as well! With such a level of "stone club" analysis at work, one can only imagine what other innocent e-mail is being injected, inspected, detected, infected, neglected, and selected by the "sophisticated" algorithms of filtering programs to be flagged, reviewed, dropped, banned, burned, or trashed. Lauren Weinstein <lauren@pfir.org> lauren@vortex.com lauren@privacyforum.org Co-Founder, PFIR: People For Internet Responsibility - http://www.pfir.org Moderator, PRIVACY Forum - http://www.vortex.com
For some years, I have been concurrently involved in countering spam and in designing, implementing and administering e-mail lists for marketing purposes. In both of these endeavors, as in much of life, heuristic (trial-and-error) methods are commonplace. Heuristic approaches to the development of spam filters tend to be somewhat effective. If one receives 100 pieces of spam over a reasonable period of time containing a given word or phrase, and no legitimate mail containing it, it is statistically probable that filtering mail based on that word or phrase will block at least some spam, and little or no legitimate mail, going forward. Of course, such simple heuristics are not without their risks. We recently sent an issue of our periodic customer newsletter which contained the phrase "sizzling summer." The marketers love their alliteration — in fact, the exact same phrase appeared a few days earlier in a mailing by another company in our market segment! Unfortunately, a small number of sites using simple heuristic filtering like that I described above took offense at our use of the word "sizzling," which apparently now indicates pornographic material. A better method might combine heuristics with the scoring capability in some mail server software (I'm personally familiar with Exim), incrementing or decrementing a counter based on the occurrence of given words or phrases, with actions depending on the final value of the counter. Thus, if "sizzling" is a +1 word, "video" a +2 word, and "sex" a +3 word, a threshold of 3, 4 or 5 might be used for blocking. Dan Birchall - Palolo Valley - Honolulu HI - http://dan.scream.org/ Peruse my opinions, at http://dbirchall.epinions.com/user-dbirchall [Still too many false positives and false negatives. PGN]
How do you ascertain the age of a virtual individual in an electronically synthesized image? In the real world, you can ask for some identification. My sister was frequently carded in bars (when the legal drinking age was 18) until she was 26, because she looked young. My son told me a story of not being carded at 16 when the guy in front of him was carded at 20 (when the legal drinking age was 21). Obviously you cannot reliably determine age by appearances. Perhaps you could look at the creation date of the file? ;-) [That's not very reliable either. PGN]
My name is Matt Giger and I write the EarthBrowser software that you have recently purchased us. I am writing to inform you of about a recent scam being run on our customers. This first report was about 5 PM on 6/6/01 from a customer who purchased EarthBrowser just yesterday. Apparently some files with customer information on our server have been accessed. Let me assure you that your credit card information is safe since we never store that information on our server. Also we purge all customer information on a daily basis so the amount of information they obtained was minimal, just your name, address, e-mail address and EarthBrowser serial number. The reported scam e-mail looks something like this: Please confirm [its] registration. Correct Purchase Information You account: http://www.earthbrowser.by.ru/3004001065-010605214102678/index.htm This poorly written e-mail sends you to a Web site in Russia which is an exact copy of our purchase page and presumably sends the information you enter to the thief. If you enter your credit card number on this page, they will then have it so please do not enter any information. Hopefully the poorly worded e-mail and the suspicious Web address will alert most to the fact that this is bogus. If you have received an e-mail like this one, please let me know as soon as possible so I can trace exactly how long ago they gained access. I apologize for having to warn you of this, I am taking steps to insure that our customer information remains safe. I promise to let you know of any such scams in the future, but please help me out by letting me know if you get any strange contact trying to use our relationship with you to obtain any information. Matt Giger, Lunar Software, Inc. mgiger@lunarsoft.com
A couple of months ago I was replying to a expert-witness report in an arbitration and found that his years of service calculations were wrong by four years. Then last week I received an excel file from the other side's lawyers in the case and noticed that when I cut and paste a column of dates they all automatically went back four years and a day. The problem arises from incompatibility between the 1904 date system used by excel in mac and the 1900 date system used in windows. This is a known and documented feature of excel: http://support.microsoft.com/support/kb/articles/q180/1/62.asp However, a quick search on the Web and in the Risks Forum archives suggests the risk isn't that widely appreciated. Even if one knows about the anomaly and checks for date system compatibility before cutting and pasting dates, one still could receive files from a source that already had corrupted dates. There would be no way of knowing (other than common sense if the results are not credible). It seems to me that the errors introduced into spreadsheet calculations will tend to be systematic rather than random because: 1. they will often occur when two or more sets of data are being consolidated and thus the errors will apply to the population of one set but not to the other and 2. the direction of the error will be influenced by the prevalence of macs or pcs in different institutional settings and fields, e.g., macs in universities & design and pcs in businesses & finance. Thus, for example, dates systematically advance from businesses to universities and recede from design to finance. This makes collaborative work between institutions and professions especially vulnerable. The first time (that I know of) that I encountered the problem was a practical instance with a potentially significant economic impact on several thousand employees. The fact that the data was presented in the course of an adversarial process was probably crucial to the error having been detected. I am wondering why there aren't more reports out there of encounters with this problem. Is this bug flying under the radar? Tom Walker, Bowen Island, BC 1-604-947-2213
I was recently assigned to take over a system that processes and sends data to a wide variety of scientific agencies that depend on said data. In particular, I've been asked to understand the system well enough to maintain and troubleshoot it. Naturally, the system, both software and hardware, was created "in-house" by contractors. Nothing like anything I'd experienced before. When I requested documentation, I was told there was none. The last person who had to work on the system had produced a draft of user documentation, but it was incomplete. So, I contacted the poor soul who had worked on this system before me, the one who had produced the incomplete documentation. (We'll call her Joan.) Joan was only familiar with the part of the system she had worked on (the user interface, really). So I asked her about the two people who had designed and implemented the system in the first place. I thought that they could perhaps help me with some of the questions I had. One of them had left the company that originally employed her, and wouldn't return phone calls. So I asked Joan about the other designer, who seemed to have done the bulk of the work anyway. "He's dead," Joan told me. "Heart attack." The risk? If you skimp on documentation while designing a custom system, you may find that you don't have time to go back and do it later, with serious consequences for those who follow you. This problem should be familiar to most readers of RISKS, but it bears repeating. As I write this, a problem has come up with the system and no one is even sure if it is hardware or software. When dealing with such a system, you cannot guarantee you will be able to talk to the original designer (and the only one who understands the system fully), and it might be because they've left more than just the company that originally produced the equipment. Sic transit gloria mundi... Kirt Dankmyer — 757-824-2283 — kirt.dankmyer@csoconline.com CSOC UNIX System Administrator — Wallops Flight Facility [Of course, Wallops Island is where a lightning strike hit the missile launch platform when a missile was waiting to be launched to test the effects of lightning — and resulted in the missile accidentally being launched. PGN]
BKININSC.RVW 20010511
"Inside Internet Security", Jeff Crume, 2000, 0-201-67516-1, U$29.95
%A Jeff Crume crume@us.ibm.com
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2000
%G 0-201-67516-1
%I Addison-Wesley Publishing Co.
%O U$29.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com
%P 270 p.
%T "Inside Internet Security: What Hackers Don't Want You to Know"
Recently I started teaching a new class. During the introductions, one
student admitted that he wanted to learn how to break into systems since
that would teach him how to protect them, right? In the first place, I
don't believe him. In the second, his thesis is seriously flawed. Yet that
is the type of argument Crume seems to be making in the introduction to this
book: learning how to hack will teach you how to protect yourself. It
doesn't work that way. Knowing how to exploit a buffer overflow in
Microsoft's Internet Information Server doesn't teach you anything about the
type of systems development practices that will keep you from leaving buffer
overflow loopholes in your own programs.
Crume does, however, present some good, if basic, security advice. After a
bit of a rocky start.
Chapter one says that there are weaknesses in the net. Big surprise.
Chapter two says that the Net is possibly dangerous. About the only
reliable information you'll get out of chapter three is that hackers differ.
By chapter four, though, the book has settled down. Here we get a decent
introduction to risk analysis, stressing that some risks are not worth
protecting against. There is some solid advice about security policies in
chapter five, most notably, have one.
Chapter seven lists some good general points to keep in mind, which then
become the titles of the remaining chapters. There is a clear, if not
terribly detailed, explanation of what firewalls are and do, in chapter
eight. We are warned to be wary of insiders in chapter nine, which also
points out that not all "insiders" are actually inside. Chapter ten
outlines some of the aspects of social engineering. A detailed discussion
of passwords, in chapter eleven, even covers tokens and biometrics. Network
and packet sniffing is explained in chapter twelve. Chapter thirteen is
weak. Ironically, it is the first chapter to touch closely on the items
Crume implied in the introduction, and looks at software vulnerabilities.
But these loopholes are very difficult to deal with, and the material here
isn't much help. Chapter fourteen is helpful in pointing out that factory
set defaults can be dangerous. The title of chapter fifteen ("it takes a
thief to catch a thief") seems to be suggesting that you hire hackers.
Actually, it merely suggests that you learn the vulnerabilities that they
know. However, it isn't very useful in pointing the reader in the right
direction. Chapter sixteen offers a grab bag of anecdotal reports of
recently exploited vulnerabilities.
And, of course, I have to pay special attention to chapter seventeen,
on viruses. Well, Crume makes mistakes, but he doesn't make any
really important ones. The background is reasonable, and the advice
is sound.
Chapter nineteen provides a good overview of cryptology, but some of the
more important points get buried in the stories. (There is more material
provided in appendix A.) Backdoors and end runs are discussed in chapter
twenty. Chapter twenty one points out that even "harmless" defacement of a
Web site can have serious consequences, while twenty two says the information
is valuable and a good defence. Chapter twenty three finishes off with a
look at some emerging technologies that are bringing forward new security
concerns.
One note that I should make: the text doesn't have all that much to say
about the Internet, as such. Most of the points deal with security on a
general basis. Which doesn't necessarily make it any less useful.
This book can be read completely in a day. And, for most managers and
business people it would be a day very well spent. While some chapters are
weak, roughly three quarters of the material is both reasonable and
technically sound, a match that happens less often than one might wish.
This is definitely a volume to get to pass around among all employees--and
to provide to all newly hired managers.
copyright Robert M. Slade, 2001 BKININSC.RVW 20010511
rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer