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…
>Subject: searoom-l V1 #394 >searoom-l Saturday, 15 March 1997 Volume 01 : Number 394 > [...] >Date: Sat, 15 Mar 1997 00:03:57 -0500 (EST) >From: John Berg <firstname.lastname@example.org> >Subject: N.T.S.B. issues report on the grounding of the Royal Majesty > > Royal Majesty (Panamanian-registry 32,000-gt, 2,700-dwt, 173-meter/568 >foot, 1,056 passenger capacity ship built in 1992) ran aground at 2230 10 >June, 1995, on the sand Rose and Crown Shoal 16 kilometers/10 miles east of >Nantucket Island, Mass., because the crew was inattentive and relied too >heavily on a computerized display, according to a U.S. National >Transportation Safety Board report issued 12 March. The ship ran aground >while sailing from St. George's, Bermuda, to Boston with 1,509 people >aboard. She was 27 kilometers/17 miles outside shipping lanes and with >6.1-meter/20-foot draft, the bow ran aground in 3.4 meters/11 feet of >water. Five tugboats refloated the ship at high tide with damage limited to >stress cracks in the hull and fuel tank. Including lost revenue, the >incident cost U.S.$7 million. The N.T.S.B. report said the crew members were >not adequately trained in the use of the automated capabilities of the >ship's integrated bridge system, including an STN ATLAS Elektronik G.m.b.H. >Navigation Command System (NACOS 25) with two input ports for a Raytheon >G.P.S. receiver and a Raytheon Loran C receiver. Crew members' training was >limited to on-the-job knowledge from each other, with no performance or >training standards, no inspections and no certifications. An hour out of >Bermuda, an antenna cable connection on a G.P.S. receiver was severed. The >system defaulted to dead reckoning when the cable was disrupted, and did >not account for wind or sea changes. The automated display therefore showed >the ship on course. The ship failed to acknowledge alarms, visual warnings, >aids to navigation including channel buoys and lights and differences in >water color. Norwegian Cruise Line recently announced plans to buy the >Royal Majesty from Kvaerner A.S.A. for U.S.$190 million. >[...] > World Maritime News is distributed by electronic mail every Friday. >Due to its distribution beyond the original format both in style and >medium, it is preferred that it be left intact or that World Maritime News >and/or Steve Schultz (email@example.com) be attached with excerpts, >especially those excerpts in which structure and tone are not changed from >that used in the World Maritime News. If in doubt, please ask. Although >every effort has been made to verify the accuracy of the information >presented, I do not assume any liability arising from its use. >[...] End of searoom-l V1 #394
CALPIRG (a public-interest research group) has a new Theft Identity Guide (``What Can Consumers Do To Avoid Becoming Theft-of-Identity Victims?'') for any of you who want to know what you can do to protect yourself against having your identity misappropriated. I worked my way down the PIRG Website and found the Guide at http://www.pirg.org/calpirg/consumer/privacy/toi/prevent.htm . If you cannot get a Web copy, send e-mail to firstname.lastname@example.org, or call 1-800-533-4449 within the U.S., or write to CALPIRG at 11965 Venice Blvd #408, Los Angeles 90066. If you are a new RISKS reader and don't know about the potential risks, the RISKS archives contain a startling number of cases involving individuals whose identity has been usurped, purloined, lost, or otherwise impaired. Some of the early cases are summarized in my Inside Risks column, CACM, 35, 1, January 1992, and more recently in my RISKS book (Computer-Related Risks, Addison Wesley, 1995, pages 194-199). The RISKS archives include (among others) the following cases — itemized in the Illustrative Risks summary (ftp://ftp.csl.sri.com/illustrative.PS), with references (S i j) to volume=i,issue=j of the ACM SIGSOFT Software Engineering Notes. Most of those cases were initially discussed on-line; grep away if you want the original items. Repeatedly detained (S 10 3, S 11 1), Terry Rogan wins rights violation case (S 12 4); settles for $55,000 (S 13 2) Other cases of false arrest due to computer database use: C.R. Griffin license not suspended; Sheila Jackson Stossier mistaken for Shirley Jackson; two Shirley Jones, diff birthdays, 6", 70 lbs diff (S 10 3) More computer-inspired false arrests, libel, etc. (S 12 3) Michael W. Klein, mistaken identity due to outrageous mismatch (S 20 2:7) Identical database record names cause nasty tax problem in Canada (S 12 4) Two Belinda Lee Perrys share the same birthdate (S 21 4:13, R 17 88) Nonupdated stolen-car database; one owner shot, one roughed up (S 21 4:14) Risks of naming files ``core" (S 21 2:18) Risks of non-portable configuration files (R 17 62) Mistaken-identity nightmares: Foster, O'Connor, Taylor, Stapelton (S 13 2) Richard Sklar falsely apprehended three times because of impostor (S 14 2) Roberto Hernandez falsely jailed twice; won $7000 first time! (S 14 5) Joseph O. Robertson in for 17 months despite contrary evidence (S 14 5) Martin Lee Dement 2 yrs LA County jail; fingerprint sys not used (S 14 6) Another bogus identity: Teresa Stover alias' VA DMV license; `perhaps thousands' of fraudulent licenses `bought'? (S 16 3) Driver arrested in computer muddle: two cars with same plates (S 17 1) Police raid wrong house (twice), due to uncorrected database typo (S 17 1) Two Russ Hamiltons with same birthdate; wrong one jailed (S 19 3:6) Imposter usurps Clinton Rumrill's existence (S 19 3:7) New license sent to imposter who plagued Charles Crompton (S 19 3:7) Rented car falsely listed as stolen leads to false incarceration (S 16 4) ATM photo of wrong person sent as rapist/robber; `downloading error' (S 16 4) Motorist gets citation based on photo, responds with photo of money (S 16 4) Impersonator transfers numerous traffic citations to victim (S 17 2) Two Steven Reids in Montreal sharing same birthday (S 18 1:22); See also Don Norman, et al., on-line (RISKS-14.12-17) on Name Problems
Recently, the Risks Forum listed an article describing successful attacks on smart cards. I reviewed the article and talked to a friend at a chip reliability lab. He believed that his lab could use those techniques to break the card security in a few days from a standing start. Once the system was up, they could do it in hours. Based on that, I believe that the challenges to smart cards are very real and that the cost of breaking a smart card is low enough to make it worth while for organized crime to use. Card Technology magazine (intended for executives in the smart card arena) in the Jan/Feb 97 issue had an article titled ``Facing the Smart-Card Security Issue''. (Here are some selected quotes.) "The industry needs to put the latest attacks and methodologies into perspective by taking a good look at the security of their entire systems. As we have heard before, any chain is only as strong as the weakest link. This is definitely true for smart card systems. Most of the attacks of recent days are classified as class 3 attacks, which means it would take millions of dollars of equipment, and hundreds of years of computing power, to actually break into a transaction. In most cases, there are many easier ways for some of this information to be obtained. A through risk analysis must be performed at every level of the system to determine what is being protected, the value of that asset, and how much security is required to protect that asset." "The smart card is an intrinsically secure device." "Are smart cards 100% secure? Claiming that any system and/or technology is 100% secure is irresponsible. Any system can be compromised given the appropriate amount of resources. The main consideration for any system is whether the level of security meets with the level of effort that an entity would be willing to expend in order to compromise the security." "Pay TV systems are probably the most publicized cases of security attacks and compromises of smart cards. Once a pay TV system is compromised, new cards are sent out to subscribers to update the system." "A third paper was recently presented at the USENIX Electronic Commerce Workshop in Oakland, Calif. This paper "Tamper Resistance-A Cautionary Note" goes into more detail on how a smart card can be manipulated to produce a fault in a particular calculation. Its authors also have published a paper entitled "Improved Differential Fault Analysis" which reviews the work of both Bellcore and Shamir, putting it into a smart-card context." The major risks are that people may believe that the smart card is still too expensive to break and thus not put in the checks to detect counterfeit cards. The risks are not in breaking one transaction, but in counterfeiting cards that the system can not detect are counterfeit. Whoever issued the original cards could wind up paying large sums to cover transactions from counterfeit cards. Visa recently ran a contest where the prize was a smart card containing $2,500 value. That much benefit on one card makes the cost of counterfeiting look very attractive. David Randolph Prairie Trail Software, Inc [A smart card strategy may be to understand the risks of smart-card strategies. PGN]
Shockwave is a Web browser plug-in from Macromedia http://www.macromedia.com that plays animated multimedia content. A security hole that allows a Web server to read e-mail files on a client browser's machine is described by David de Vitry on http://www.webcomics.com/shockwave/ with an example Web page that reads Netscape Navigator e-mail files on Windows 95 and NT, how Shockwave can be used to read any local file on the client machine and send data to the server, and Macromedia's response and plans for fixes. This site also gives yet another variation that allows the server access to any Website that the client has access to, even Websites on local networks and behind firewalls. See also http://www.wired.com/news/technology/story/2548.html . Another article at http://www.macintouch.com shows how the same technique can be used to read Eudora mail files on a Macintosh. Relevant to the previous discussions on RISKS about Authenticode, de Vitry points out that users of Microsoft Internet Explorer who enter a page with a Shockwave movie on it are presented with an Authenticode digital certificate signed by Macromedia, not by the author of the possibly malicious movie. — sidney markowitz <email@example.com> [Sidney kept sending me later updates from Friday and Monday, which I have incorporated. The date/time stamp is from his latest message. PGN]
A couple of weeks ago I tried to use www.movielink.com to purchase tickets for "The Empire Strikes Back" at a theatre in New York. I've used this service many times in the past (at other theatres). For those who haven't used it, it works over https - you select a movie showing, give it the number of tickets, credit card number and expiry date. It gives you a page saying "You must remain on this page", while it processes the transaction, and then gives a success or failure message. When you get to the theatre, you swipe your card in a card reader, and the tickets pop out. For this movie, I got a failure message so I tried again. This too failed, so I gave up and bought the tickets the old fashioned way. I just checked my credit-card bill, and I was billed (by the theatre, not some ticket agency) for both attempts. How many people keep an accurate track of the movies they saw a month ago? [Especially risky if you see a lot of films. You may be suffering from Jedi Red-Eye, and spending too much time in E-Wok mode — some sort of electronic Chinese-restaurant syndrome? PGN]
Well, I'm getting to experience the Year 2000 problem first-hand. My bank sent me a Visa debit card with an expiration date of January, 2000 last month. I didn't notice the problem until I first tried to use the card. The local grocery store's card reader wouldn't handle it; when it phoned the bank, it came up with some error code the checker didn't know about, and wasn't about to try to figure out. At another store, the card reader also phoned the bank and came up with a strange error code. When the clerk phoned in the problem, he found the error message explicitly meant "your firmware is out of date, look in your manual for the process for upgrading the card reader's software." I've also hit one store that has a combination cash register and card reader that appears to date from the early '80's. Their card reader caught the date problem before phoning in the card, and thus wouldn't allow the bank to be contacted. The clerk assumed the problem was a date problem and misread the "valid from" date as the expiration date in his quest for something that looked (to his eyes) as a valid date. The owner of the store didn't seem to understand my explanation for the problem, either. In most of the cases where the card's been rejected, the clerk's been completely confused by the card reader's reaction and isn't sure what to do. Luckily, by issuing error codes at the bank end on Y2K problems, the bank can probably figure out which card readers are running old software, then lean on the store managers to update the software. This minimizes some of the risks of untrained salespeople not understanding the problem enough to tell their manager to update the card reader. I'm going to try very, very hard to have one card with a 1999 expiration date at all times for the next few months. Debugging New York State one card reader at a time, Robert (Other RISKS articles about VISA's warnings to member banks: RISKS-18.62, "current score is Y2K 1, Visa 0", RISKS-18.74 "VISA fines banks with Y2K problems" Other first-hand stories RISKS-18.65, "Year 2000 and expiration dates", Salesmen canvassing for non-Y2K card readers RISKS-18.68, "Year 2000 Sharks") [Another case forwarded to RISKS by firstname.lastname@example.org (Tony Lima). PGN]
> he told me of a colleague who used nonsense words as identifiers ... Since COBOL has about 300 reserved words, a lot of programmers have taken to using nonsense words for variable names, to avoid reuse of a reserved word. This makes it much more probable that a date field would have a meaningless name, than in most other languages. Amos Shapir nSOF Parallel Software, Ltd., Givat-Hashlosha 48800, Israel email@example.com +972 3 9388551
While I understand, quite easily, the feeling that one (or in this case one's friend) has tried to do a good deed and it hasn't gone unpunished, I nevertheless think Mr. Drake is missing the point — which is that industrial-strength random numbers merit industrial-strength delivery. The presumptive argument for this service is that the numbers provided by this system are better (more random) than the user could obtain on his own. While the source of these numbers may well be superior, the method of their delivery may well render them worse than the user could obtain on his own. Mr. Drake says: > The Risks question here is, just what level of paranoia is suitable here? > If you're paranoid enough to think you need quantum-randomness as > your random number source, you should definitely want extremely > high security in how they are delivered. Interestingly, this is the precise converse of the usual error: getting your crypto right and your randomness wrong. The risk, of course, is the same: lavishing care on one part of a security system while ignoring the rest. -Ekr [Eric Rescorla]
The Ariane 5 failure surely is the winner of the ongoing contest for "Most Damage Done Per Line-Of-Code Changed" - $1.8B / 0 [!]. I fully agree with Kevin Quinn's point (RISKS-18.90): no formal methods would have detected the problem - its roots lie within the realm of human communications and tying together seemingly-unrelated physical information, rather than programming. [Coming through, awry? Comment by PGN]
The house I live in (in Portland, Oregon, USA) was formerly owned by a family with many teenagers and a home-based business so they had at least 5 telephone lines. I have one phone line. However, I get a dial tone on 4 of the 5 lines coming into the house. I believe this happens when the local telephone service provider does not physically disconnect the wiring when service is canceled. When they subsequently reassign a wire pair from the canceled service to a new customer, they make a new connection to the wire pair. Now the wire pair can be used by both the old and new customer and the new one gets the bill. It's also possible the wires are accessible to people other than you and the phone company. If you live in an apartment building, the phone lines for all the residents probably are accessible from a single box in the basement. If that box is not sealed with a phone company seal, anyone with a telephone and access to the box could have made the calls. Louis F. Fernandez Sequent Computer Systems Beaverton, OR 97006-6063 firstname.lastname@example.org
Many years ago, when I took up residence in New Jersey to work for what was then a major electronics company (and what is now a minor subsidiary of GE), I had some problems with the phone in my apartment. At first it didn't work at all, but the phone company was finally able to get it working after about ten days. It had bad crosstalk, but I took that to be a problem with the old lines in the area. About a month later I got my first bill. There were toll charges totalling over a hundred dollars, even though I had only used the phone for about ten brief calls. I called the business office and got the usual "the computer doesn't lie" response. (Based on the numbers called, the charges appeared to be associated with a construction business, but the folks in the business office seemed unimpressed with the argument that I'd have no reason to make such calls). Not knowing what else to do, I called the repair service and complained that the lines must be crossed somewhere . A few days later the crosstalk disappeared (and later bills revealed that the improper billings ended on the same date). Unfortunately, the repair service didn't communicate any of this to the billing department, and I continued to be billed for the bogus calls. Only after I insisted that the folks in the billing department inspect the service records did they grudgingly agree to adjust my bill. Risks: Obviously, the "the computer doesn't lie" syndrome. Beyond that, though, three more observations: 1) It is arguable that the repair personnel, when they corrected the apparent wiring error, should have recognized that it could have generated bogus billings and communicated this information to the billing department, especially since the service call was initiated with this suspicion. 2) Some consideration should be given in the design of equipment to the prevention of this sort of error. Close as I can tell, the problem was probably some sort of simple wiring error — either a short between adjacent wires or a "split pair". That such a reasonably likely error could go undetected and, further, produce erroneous billings, indicates a lack of "robustness" in the design. 3) Consumers are increasingly at the mercy of various forms of automated, computerized billings, but increasingly there is no "hard copy" or independently verifiable record of the transactions. In a sense this is valid justification for an increasing level of technophobia. Dan Hicks http://www.millcomm.com/~danhicks
I don't think the following story will help solve the mystery of the calls to Guyana, but it demonstrates a risk with "intelligent" pieces of telephone equipment. I once found several calls on my International telephone bill that I was doubtful that I had made. Thankfully, they were all very short. The following month I called a friend in London, I was living in Tokyo at the time, but the call was answered by the operator who asked which number I was calling. Since I always used the single keypress quick dial feature I had difficulty in answering the question but looked in my address book, told the operator, and the call was put through. I asked my friend why the calls were being stopped and she said that they had been suffering from calls where no-one spoke. Later, I noticed that there was an extra LED lit up on my answer phone and I looked in the (Japanese) manual to find out what it meant. It meant that an option designed to call a pager was enabled and that every time someone left a message on my telephone answering machine when I was out, the telephone was subsequently calling a pager number. I entered the sequence to find out what number it was calling and found that it was calling my friends number in London. I then realized that a couple of months previously, when I had first entered her number as a single keypress number, it hadn't initially worked and that I had accidentally entered it as the pager call number. The key sequences do this were similar to the single keypress entry sequence. Since I hadn't programmed a sequence to be sent to the pager, my telephone remained silent when it called my friends number. I didn't even know that the telephone had this feature as I only read the parts of the manual I was interested in. The problem was hidden since it only occurred when I was not there to answer the call. Also the user interface of the telephone was very limited making it easy to make mistakes and hard to find them. Had I been programming a single keypress dial number to a recorded service in London, I would possibly have run up an enormous bill.
This happened to me. A neighbor had made a physical tap into my phone line and used it to make many expensive long-distance calls. A switch cannot, of course, distinguish this from your own telephone, since it happens on the same wire. In my case it took several months, plus the threat of legal action, to persuade the telephone company to investigate the problem down to the level of the wires in my block of dwellings.
If you are certain that the call was not made by someone in your house, then the two most likely explanations of their origin are: 1) You have a cordless phone, and someone with a similar model of phone made calls on your line from near your house (e.g., from a nearby house, or from a car parked nearby). Some complicating factors: Most cordless phones will not allow calls to be made when the handset is in the base. But you may have left the handset out of the base. Before being able to do this, the thief would have had to figure out what model of cordless phone you had. But he could have seen you talking on your phone in your front yard, or he could live nearby and accidentally picked up a conversation on your phone, causing him to become aware of the fact that his handset is compatible with your phone. Most cordless phones nowadays have some sort of security code exchanged by the handset and base before the base will allow a call to be made. But you may have a phone without such a system, or the attacker may have figured out (intentionally or accidentally as described above) the code used by your phone. Of course, if you don't have a cordless phone, all of this is irrelevant :-). 2) The thief tapped into your line outside the house to make the calls. This isn't that hard to do. The telephone handsets used by repairmen are not that hard to come by, and all the thief would have to do is find the junction box for your telephone wires, open it, and clip a handset onto the line. Even if the junction box is inaccessible or locked, the thief could find the wires themselves, strip the insulation off of them, and clip directly to the wires. If this is a possibility, then you should figure out where the wires for your phone line enter your house, and trace them back as far as you can (e.g., until they claim to the top of a telephone poll you don't want to (or aren't legally allowed to) climb). Make sure there's no place where the wires are stripped, and also make sure that any junction boxes and other wiring cabinets which provide access to the wires are locked. If you find a junction box or wiring cabinet outside your house that isn't locked, you are almost certainly justified in calling CableTel and demanding that they (a) secure it and (b) don't charge you for the calls you did not make. However, they may have thought of this first, in which case they may have already sent out a repair crew to find your junction box and lock it. Jonathan Kamens | OpenVision Technologies, Inc. | email@example.com
Please report problems with the web pages to the maintainer