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…
Due to a Majordomo configuration glitch, all new subscriptions between last Friday afternoon and Monday morning went into a BLACK HOLE. Sadly, the folks who need to know about this probably won't see this until they get tired of waiting and try again — if they ever scan the archives. SORRY!
The Supreme Court has let stand a lower court ruling that frees Internet service providers such as America Online from legal liability for information one subscriber circulates to millions of others. The appeals court said that federal law "plainly immunizes computer service providers like AOL from liability for information that originates with third parties." The case is Zeran vs. America Online, 97-1488. (*San Jose Mercury News*, 22 Jun 1998; Edupage 23 June 1998)
We have wittingly fallen victim to a behavior modification problem that has resulted from the way we think technology works (or should work). Or, perhaps the way we FAIL to think about it. Either way, it appears to be life threatening. Two cases in point: Last week, a smoky fire broke out in the basement of a Chase Manhattan Bank building on Wall Street. People working on the 22nd floor of the building noticed the "lights started to flicker and then the phones went dead, but the computers were still working." Apparently the company's UPS kicked in, allowing the computers to remain functional. However, a person's perception of a power failure is that either everything stays on (power) or everything shuts down (failure). The failure of the lights and phones would lead one to believe the power has been lost. However, the computers continued to run, leading the people to confusion. "We all looked at each other because we couldn't figure out what the heck was going on." They remained at the helm for another 20 minutes before someone smelled smoke. Then a person from another part of the building warned them to leave. At the end, thirteen people were injured. The second case involves a horrible traffic accident where the driver and passenger were injured and pinned in a flaming vehicle. A witness dialed 911 on his cellular phone. U.S. residents "all know" that 911 is the number to call to request emergency equipment. What we don't "all know" is that cellular calls to 911 do not automatically provide an Automatic Location Identifier to emergency responders (although a few 911 cell ALI systems have sprouted since this accident happened). In Massachusetts, where this accident happened, all cellular 911 calls are routed to one of two State Police barracks, then are transferred to the responding agency. This 911 call was answered 50 miles away. The witness was fairly spun up because of the immediate danger to the accident victims. Due to his excitement, the 911 operator had difficulty understanding the caller, resulting in a delayed response. The victims were finally extricated, treated at a local hospital (multiple fractures, burns, sucking chest wound), and eventually released. The risk here is that the witness couldn't fathom that the 911 call wasn't sent to the closest 911 Public Safety Answering Point, and that the 911 operator had no indication of the accident location. He expected technology to work the way he *thought* it should work. The public at large seems to have a notion that technology will always perform in the manner perceived, with little notion of how that perception is developed. I suspect, in our frantic pursuit of the newest and fastest whozywatts, this will be the case for a while, and it's our fault. Chip Seymour <cseymour@mitre.org>
A report released earlier this week by the Software Publishers Association and the Business Software Alliance shows the industry lost $11.4 billion to pirates who produce illegal copies of software. SPA now acknowledges that its strategy of settling infractions with a fine and a confidentiality agreement has not been very successful, and vows to begin pressing charges and publicizing the names of offenders. "I don't like doing that, but it serves as an education to companies in a similar situation," says the SPA's director of anti-piracy efforts. "If they want to keep ripping off our members, why should we treat them nicely?" Some areas have shown improvement — Europe, which had a piracy rate of 90% five years ago, is now down to 50% — still, that's almost twice as high as the U.S., which is 27%. (TechWeb 19 Jun 1998: Edupage, 21 June 1998)
The Arizona Lottery suspended its new Pick 3 game when they discovered that the computer selecting the winning numbers never picked 9 (http://www.arizonalottery.com/new/pick3faq.html). The Pick 3 game had players select three numbers, 0-9. Why do I have a sneaking suspicion that their code probably looked like INT(RND * 9)? The lottery is offering refunds to players that had played 9, but they have to still have their losing tickets. I suspect that most players threw away their tickets when they lost. The lottery plans to reintroduce the Pick 3 game, using a ping-pong ball machine (as its other games use) rather than a computer. If a simple bug like this slipped through, I'd have to wonder about the robustness of their random number generator, which would be another risk. Alan Hamilton <alanh@primenet.com>
There has been quite a bit of discussion on comp.risks lately about the various risks associated with relying on GPS systems. I read about another one today that not many people will have thought of. (Daily Telegraph, June 23, 1998) When a body weighed with an anchor was caught in a fishing boat's nets, police launched a murder investigation. After identifying the body (by the maintenance records for the Rolex Oyster Perpetual Date Chronometer it was wearing!), their invesigations uncovered a man who had stolen the victims identity and allegedly murdered him to prevent it being discovered. The nice bit is that they found the GPS navigation unit for his yacht in his garage. The GPS route history showed that he had been close to the area where the body was found just about the time that it was believed to have been dumped! After that, it was all downhill... He should have dumped the GPS, too. Ian Cargill CEng MIEE Soliton Software Ltd.
WorldOnline, one of the large dutch ISP has suffered a number of security failures recently. These were mainly attributable to human error and weak OS level security measures. The most prominent mistake was to assign passwords to users by using a combination of the first four letters of their userid and a 4 digit code. I even doubt that the 4 digit code is randomly chosen but even if it is, cracking an account with this knowledge is pretty easy and straightforward. In an attempt at damage control, WorldOnline last week stated that it's system is secure and that users should not worry, although they do not feel responsible for breakins on websites that they host. To prove their point and to get some positive publicity, they even launched a competition with a prize of $7400 for the first reproducible crack. The prize was claimed within a few days by a cracker who managed to extract thousands of private e-mails from a mail server. Another team cried foul because the system they had hacked into (running the internal helpdesk) had been abruptly switched off in an attempt to stop the crackers. The dutch provider association (NLIP) has denounced the competition as a cheap publicity stunt. Paul van Keep
I found this little gem today while searching for something completely unrelated. A person had listed, on his on-line resume (or curriculum vitae, if you prefer), his name, birth date, social security number, marital status, and home address. It's bad enough when organizations collect them, but to give such information out this freely...? The risks? Just the usual ones of posting such information on-line, and not having it located behind any sort of security screen. Less obvious? The home page owner didn't realize the risks ... and there's apparently no-one else at the site responsible for checking content. This is perhaps understandable for someone's home page on a commercial server ... but this one was part of a department's staff listing. John Lewellen <Lewellen@aps.anl.gov> Advanced Photon Source, Argonne National Lab.
A Word macro virus called WM/PolyPoster was recently found. As the number of macro viruses is soon reaching 3000, there's nothing special about this. However, under the right conditions, this virus sends copies of a victim's Word documents to 23 different Usenet newsgroups under subject lines like "New Virus Alert!," "Important Princess Diana Info" and "How to find child pornography." Risks are obvious and three-fold: 1. Private and confidential data is disclosed to the world 2. When unsuspecting fellow users download and read these documents, they get infected themselves 3. The user's name get's archived to services like DejaNews as posting messages related to software pirates or child porn. More details at: http://www.DataFellows.com/news/pr/eng/fsav/19980618.htm http://www.DataFellows.com/v-descs/agent.htm This virus is not known to be widespread at this time. Mikko Hermanni Hypponen - Mikko.Hypponen@DataFellows.com Tel +358 9 859 900 Data Fellows Group, PL 24, FIN-02231 Espoo, Finland http://www.DataFellows.com/
The California Public Utilities Commission has voted to allow Pacific Bell to offer a service that allows customers to reject calls from people who have blocked transmission of their own phone numbers, a service called "anonymous call rejection" (ACR). The ruling is an attempt to balance the rights of caller and the party being called. Consumer advocate Charles Carbone explains, "People are pretty passionate about ACR and complete blocking and select blocking. I get people who call up and say, 'I consider complete blocking a critical issue and one that protects my privacy,' and from people who say, 'It's my right to know who's calling me and I don't want to take a call from someone who doesn't want to tell me who they are.'" (*Los Angeles Times*, 22 Jun 98; Edupage 23 June 1998)
>There is a Year 2000 problem with the SIR-C processor ... Once in a while, economics has something to contribute to RISKS issues. It sounds like the SIR-C processor is functioning as what economists call a "public good". If the manager of the SIR-C processor doesn't have the resources to contemplate a fix, perhaps the user community does. The problem is determining how much the user community would be willing to pay. Academic economics has pretty much solved the problem of obtaining accurate bids for a public good. This is generally done with a "Groves Mechanism" (see Groves, T. and J. Ledyard, 1977, "Optimal allocation of public goods: a solution to the `free rider' problem", Econometrica 45, 783-811.) This is a bidding scheme where it can be proved that the optimal strategy for the bidders for the maintenance of a public good is a truthful assessment of what the good is worth to each bidder (which economists equate with the most the bidder would pay). If the sum of the bids exceeds the cost of the public good, each bidder is asked to pay an amount less than or equal to their bid. But the mechanism rigs the game so that bidding more than it's true value is likely to result in bill for more than it's worth to you, while bidding less will not change the amount you are billed, but may cause the entire project to be scrapped for insufficient community interest. Daniel A. Graifer <dgraifer@cais.com>
An article in the 17 Jun 1998 *Wall Street Journal* (Robert Cwiklik, "Honest, mom, I don't even know what those @#$%& words mean", page B1) describes a program called "Secret Writer's Society" that is supposed to help children write by reading their writing back to them in automatically generated speech. Under certain conditions, however, the recitation is augmented with every obscenity in the English language. The problem is evidently that the program also reads out loud its full dictionary of words that it is supposed to filter out. Judging from the sound of the conditions under which the problem arises, some kind of array bounds check is not being done. Assuming that this isn't another in the Wall Street Journal's recent series of urban myths, it's a depressing comment on the state of computer programming. Way back when I was a college student, we were taught programming languages that automatically prevented your program from reading random swatches of memory through automatic bounds checking. This was presented as a boring and well-established technology, which of course it was. So many of the problems reported on Risks result from the failure to apply methods that were prevalent 40 years ago.
> Insert a "^Zrm *" at the right time and boom. Actually, that would be "^Drm *". Regardless, this is hardly the first problem that has appeared with ssh. At least twice before I've had to run out and update all of my machines immediately due to problems of this sort that have appeared. Fortunately, the problems appear to be publicised quickly, and a solution is available almost immediately. This appears to me to be about the best way of dealing with these problems that I can think of. It's certainly unrealistic to expect that problems will never occur in a programs as complex as the ssh suite, and, given the amount of scrutiny that this system comes under, I'm impressed that there have been only three or four incidents of this type in the last dozen revisions or so. Curt Sampson, Internet Portal Services, Inc., Vancouver, BC (604) 257-9400 http://www.portal.ca/ cjs@portal.ca
This is not a new problem. Back in the early '80s I spent a couple of years working on the real-time control software for a "hot box" detector, that sat by the track and examined wheels and bearings as trains went by and looked for wheels that were hot... it's amazing the number of failure modes that could be detected simply by looking for an excessively hot bearing. Flats were one of the things that could generate an alert. Of course it had code to allow for temperature differences between different kinds of wheels and bearings, and those caused by sunlight on one side of the train. The detector worked at up to 90 miles an hour, with a 2 MHz Z80 CPU doing all the analysis and templating of trains, and delivering alerts over the radio to the driver (using a male voice... normally female voices are easier to hear but in this case the engineer has a lot of high frequency noise to deal with). There were no identifying marks on the trains, they and their cars had to be recognised simply by the timing of the wheels as they passed the detectors. Further processing and reports were handled by a Microvax in the control center in Portsmouth, Ohio. I think it was a Microvax I... a box with less CPU power than the original Macintosh. I'm really surprised that they didn't have something better on a 200 MPH train in 1998.
> When members of the household smelled smoke, they could not immediately > call for help because their cordless phone required AC power to run. Which is why the instruction books for many cordless phones include a warning NOT to use a cordless phone as the only phone in a residence. In fact, on many of the models which my engineering group specifies and/or designs, we have this information repeated in several places (a drop-in safety leaflet, and sometimes even on labels affixed to the product, as well as RTFM). Nonetheless, despite warnings, people behave as if they are stupid... Eric Roesinger, Member Technical Staff, Communications RF Cordless Development, Thomson Consumer Electronics
When smoke detectors become popular in the '80s, I added several to my existing home. They were battery operated and the battery "chirped" for a week or two before it went dead. In 1992 I built a new home and smoke detectors were installed (BRK Electronics Model 86RAC). The primary power is AC, but the detector has a backup battery which also "chirps" when it runs low. The original batteries lasted 4 years before they ran down. [Since I was not aware that the smoke detector contained a battery, this caused a certain amount of confusion at 3 AM when the chirping started.] I am surprised that it is legal to sell AC powered smoke detectors that do not have a battery backup. Maybe the building codes in Virginia are more lenient than those in Idaho where I live. David Kipping <kipping@compuserve.com>
>A fiber optics cable was severed under 42nd Street in the Bronx, [...] There is no 42nd Street in the Bronx. 42nd Street runs through midtown Manhattan. Seth [A Bronx cheer for those of you who didn't know that. I didn't believe it for a minute, but I avoid trying to correct everything that does not look right, for obvious reasons. PGN]
I have a calling card here in Canada with Bell, the countries largest long
distance carrier. Over the weekend I discovered that the PIN number for it
had been changed. I called up customer service and asked them what had
happened. They said that *I* had changed it two days ago. I asked them
what was required in order to change the pin number, and apparently a
password (one I've long since forgotten) that's mailed out with the card is
the only way. Upon pressing further, they admit that if the caller appears
under duress, they'll change it.
The risks here are obvious, but what I find even more interesting is
that:
- they didn't log when the change actually occurred
- they didn't log the number where the call originated
- the only information they required was my name and phone number,
not even my billing address was required.
Assuming most people have calling cards, imagine what you could do by
picking names out of the phone book and calling Bell?
Max Stevens jomstevens@uwaterloo.ca
BKWBSCCM.RVW 980411
"Web Security and Commerce", Simson Garfinkel/Gene Spafford, 1997,
1-56592-269-7, U$32.95/C$46.95
%A Simson Garfinkel simsong@aol.com
%A Gene Spafford spaf@cs.purdue.edu
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 1997
%G 1-56592-269-7
%I O'Reilly & Associates, Inc.
%O U$32.95/C$46.95 800-998-9938 707-829-0515 nuts@ora.com
%P 483 p.
%T "Web Security and Commerce"
Anyone who does not know the names Spafford and Garfinkel simply does not
know the field of data security. The authors, therefore, are well aware
that data security becomes more complex with each passing week. They note,
in the Preface, that the book cannot hope to cover all aspects of Web
security, and therefore they concentrate on those topics that are absolutely
central to the concept, and/or not widely available elsewhere. Works on
related issues are suggested both at the beginning and end of the book.
Chapter one, which is also part one, introduces the topic, and the various
factors involved in Web security. The topic is examined from the
perspective of the user and vendor, and also looks at vulnerabilities at the
server site, client computer, and the network in between.
Part two concerns the user. Chapter two looks at the various possible
problems with browsers, not all of which are related to Web page
programming. Java security is only marginally understood by many "experts,"
and not at all by users, so the coverage in chapter three is careful to
point out the difference between safety, security, and the kind of security
risks that can occur even if the sandbox *is* secure. ActiveX and the
limitations of authentication certificates are thoroughly explored in
chapter four. Chapter five looks briefly but analytically at the possible
invasions of privacy that can occur on the Web.
Part three deals more completely with the question of digital certificates.
Chapter six explains the various techniques for identification confirmation.
The use of certification authorities is reviewed in chapter seven, including
the activity this can generate on Web browsers. Chapter eight covers the
steps needed to obtain a client-side digital certificate from Verisign.
Microsoft's Authenticode code signing system is detailed in chapter nine.
Cryptography must be invoked at some point for any kind of data security,
and particularly for security over insecure networks, so part four invests
some depth in the topic. Chapter ten starts with cryptographic basics,
simply in terms of the various functions cryptography can provide.
Functional limitations of cryptography, various existing systems, and US and
international regulation with respect to the technology are discussed in
chapter eleven. SSL (Secure Sockets Layer) and TLS (Transport Layer
Security) are described in chapter twelve.
Part five details technical aspects of securing Web servers. Traditional
host security weaknesses are reviewed in chapter thirteen. Chapter fourteen
looks at specific strengthening measures for Web servers. Rules for secure
CGI (Common Gateway Interface) and API (Application Programmer Interface)
programming are promulgated in chapter fifteen, along with tips for various
languages.
Commercial and societal concerns are major areas in Web security, so part
six reviews a number of topics related to commerce, as well as other social
factors. Chapter sixteen looks at current non-cash payment systems, and the
various existing, and proposed, digital payment systems for online commerce.
Censorship and site blocking are carefully examined in chapter seventeen. A
variety of legal issues are discussed, civil in chapter eighteen, and
criminal in nineteen.
In reviewing books I very often find that appendices are often filler. The
most useful tend to be bibliographies or lists of vendor contacts. Too many
seem to be mere self-indulgent filler used by the author to pad out the
book. Although it has almost nothing to do with Web security as such, I
very much enjoyed Appendix A, Garfinkel's recounting of the lessons learned
in setting up a small ISP (Internet Service Provider). (I suppose that this
could be considered valid coverage of Web commerce.) The other appendices
are more directly related to the topic, including information on the
installation of Web server certificates, the SSL protocol, the PICS
(Platform for Internet Content Selection) specification, and references.
In comparison to Stein's "Web Security" (cf. BKWEBSEC.RVW) I find it very
difficult to choose between the two. Each is readable, and each is aimed
pretty much at the same target audience. There is little to choose between
them for technical depth: each has useful information that the other does
not. Both are excellent: what the heck, buy two, they're small.
copyright Robert M. Slade, 1998 BKWBSCCM.RVW 980411
Please report problems with the web pages to the maintainer