precedence: bulk Subject: RISKS DIGEST 19.26 RISKS-LIST: Risks-Forum Digest Saturday 26 July 1997 Volume 19 : Issue 26 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** Contents: Satellite transmission snafu leads to diplomatic incident (Nick Brown) Ghost account nets $169K embezzlement (PGN) 401(k) off-by-one errors (anonymized) AOL customer phone-number availability (PGN) General Mills & AOL in sleazy partnership: Chex Quest CD-ROM game (Bruce N. Baker) Risks of relying on text search (Derek Lee Beatty) Risks of URL completion (John Pettitt) Computer jargon enters mainstream, is hit by truck (Mark Durst) The dangers of Explorer-ation (Roger Barnett) Win 95 TCP/IP Hole (Alex Klaus) Re: MD5 weakness and possible consequences (Paul C. Kocher) Re: Voice-controlled MS WORD (Tai, Christopher Kline) Re: Medical computer crashes (Jonathan de Boyne Pollard) Y2K: a different solution (Driss) Re: DEC Alpha Bug, final resolution (David Chase) Re: The truth about Usenet's Psychic Spammers! (H.Shrikumar, hymie) Privacy Digests Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 25 Jul 1997 13:56:24 +0200 From: BROWN Nick Subject: Satellite transmission snafu leads to diplomatic incident Early on Sunday morning (19 Jul 1997), a "technical error" caused the contents of a channel on a satellite operated by France Telecom, to be transmitted on another channel, for about twenty minutes. Normally this would have been merely annoying for the viewers of the affected channel. However, the viewers were in (among other places) Saudi Arabia, the channel they expected to be watching was the French government-run, general interest and news station, Canal France International (CFI), and the programme which replaced it was... a hard-core pornographic movie which should have been shown on the subscription-only, encrypted French domestic station, Canal Plus. I presume that the incident involved two channels on different satellites, since CFI is carried on Arabsat and Canal Plus on the European-oriented Telecom satellite system. My bet would be that the channel numbers are the same and the operator was pointing at the wrong satellite while hitting "Go". Results: Arabsat has cancelled its contract with France Telecom, claiming (it would appear with some justification) that France Telecom had not "honoured its commitment to respect Arabic and Islamic values". The French Foreign Ministry and the French Ambassador in Riyadh are trying to calm what has become a diplomatic incident. Nick Brown, Strasbourg, France [Also noted by Paul Johnson and and Pete Bentley . PGN] ------------------------------ Date: Fri, 25 Jul 97 10:03:16 PDT From: "Peter G. Neumann" Subject: Ghost account nets $169K embezzlement While working as a civilian military pay supervisor in the Army finance and accounting office at Fort Myer from 1994 to 1997, Teasa Hutchins Jr. caused regular military paychecks to be deposited to a bank account in the name of a bogus officer, and accumulated $169,000 for himself. He has pleaded guilty and faces up to 10 years in prison and a $250,000 fine. [Source: An item in *The Washington Post*, during one of my trips there this summer -- I forgot to record the date] ------------------------------ Date: Fri, 25 Jul 1997 11:10:28 -0400 From: [identity withheld by request] Subject: 401(k) off-by-one errors I work for a large U.S. corporation which has a 401(k) plan. For non-US readers, a 401(k) is a self-funded retirement plan: you (voluntarily) put aside part of your salary (pre-tax) and your employer (usually) matches it in part. The employee selects how to invest their portion of the money (and at some companies, how the company's matching funds are invested). As required by law, we receive quarterly reports on how much money we have in the 401(k) plan, mailed to our home addresses. This quarter, about 2/3 of employees received incorrect statements. It seems that there was an off-by-one error in matching employees to addresses. That is, if employee E1 has address A1, and employee E2 has address A2, etc., the report for E1 was sent to A2, the report for E2 was sent to A3, etc. The interesting thing was that the envelope delivered to A2 would have E1's name on the outside and E1's data on the inside. So those people who looked at the envelope before opening would realize that something was amiss. The hypothesis is that this occurred because an employee record had been incompletely deleted from the database (and no, I have no idea how that could happen). When our payroll department uploaded data to the 401(k) management company, the data was incorrectly interpreted by the receiving program. Nothing in the management company's computer system noticed that 2/3 of the addresses were mismatches with the addresses already on file. Interestingly, the last address on the list received two reports: one for the employee who lived at that address, and one for the employee who lived at the next-to-last address. The reason this affected "only" 2/3 of the employees is that those employees whose records were uploaded before the "bad" database record was encountered were unaffected. Some employees are quite upset, since other (unauthorized) people saw the balance in their 401(k) accounts and the amount being contributed. From that data, one can infer salary information ... which many people don't want publicized! We can see several RISKS here: * It was possible to modify the database records such that an employee was "partially" deleted, thus leading to the situation. * The management company's computer system did not cross-check the addresses being used for reports against the addresses of record. * Most people don't look at the address on the mail before they open it! ------------------------------ Date: Fri, 25 Jul 97 8:55:42 PDT From: "Peter G. Neumann" Subject: AOL customer phone-number availability America OnLine recently announced its intention to provide telemarketer clients with the phone numbers of all AOL customers who have not explicitly requested that their phone numbers be excluded. It was reported less widely that AOL intended to provide some sort of user transactional information as well. The AOL customer contract fine print claims that they will not release such personal information, but even finer print seems to reserve the right to do so to their business partners. (But opting out is apparently not easy.) Nevertheless, presumably due to customer complaints, AOL has backed down somewhat, and will now use that information only for its own [nefarious?] activities. Telemarketing and spamming are already out of control, and some of those activities are questionable, if not truly unethical, immoral, and in some cases illegal. But in any event, they are generally annoying and unwanted by most people. The argument that using the transaction information will permit hustlers to be selective about whom to harass seems specious and disingenuous, at best. Please stay alert. ------------------------------ Date: Sat, 26 Jul 1997 12:01:59 -0700 (PDT) From: baker@hooked.net (Bruce N. Baker) Subject: General Mills & AOL in sleazy partnership: Chex Quest CD-ROM game My 5 year-old grandson opened up a box of Chex Quest and eagerly placed the "free" CD-ROM he found inside the box onto my Mac Performa, without any adult supervision. This is not unusual because he often plays educational CD-ROMs. The box makes it sound like you get the "free" game on the CD-ROM *plus* 50 free hours of AOL. The "install" item on the CD-ROM menu installs not the game but rather, AOL. The CD only contains a preview of how the game works on, guess what? --AOL. It took me 3 days to un-install AOL and to re-install my regular service with the help of support people at The Well. General Mills and AOL neatly "cover" themselves with the following: "By purchasing this product [the cereal], you agree that, with respect to the CD-ROM game described on this package, (1) any and all disputes, claims and causes of action shall be resolved individually, without resort to any form of class action...(2) any and all claims, judgments and awards shall be limited to actual out-of-pocket costs incurred, and in no event shall attorneys' fees be recoverable...(4) you agree that your remedy for any claim, if any, shall be limited to either replacement of the CD-ROM game or refund of the purchase price of the product, such choice to be at the sole discretion of General Mills" Just what I wanted -- another copy of the same CD-ROM :-( The risk? It looks as if they knew very well what *their* risks were! How many other "free" CD-ROMs will be included with other types of products? Bruce N. Baker ------------------------------ Date: Thu, 24 Jul 97 23:20:05 -0500 From: Derek Lee Beatty Subject: Risks of relying on text search The old risk of relying on text search instead of carefully reviewing a document apparently bit the Texas legislature last session, according to an article ("Inadvertent repeal of law puts city, developers in limbo," p.1) in the July 24 Austin American-Statesman. The article focuses on the local regulatory-political implications and isn't completely clear about how the mistake actually happened, but apparently SB 932, a 68-page bill intended to abolish the Department of Commerce and create a new Economic Development Department, contained a lone unwanted sentence abolishing "Subchapter I in Chapter 481 of the Government Code." The effect of the repeal is to make the law governing land development uncertain. The paper speculated that "a liberal mole hacked into the legislative network" although the bill's author believes he and his staff accidentally repealed the development law. A government relations spokesman for the builders' association was quoted as saying that lobbyists check bills by searching for key words, and "In this case, you'd have to do a word search for 'I.'" The risk? A case of relying: - on text search instead of document review - on lobbyists to tell the legislators what laws they're making (!) - on "the computer" as scapegoat -- Derek Beatty beatty@{netcom,ibmoto}.com Austin, TX ------------------------------ Date: Sat, 19 Jul 1997 20:08:00 -0700 From: "John Pettitt" Subject: Risks of URL completion Using either Netscape 4 or Microsoft Internet Explorer 4 type "msnbc" in the address box and hit return, the URL completion will first look for msnbc in the local domain then try the common domains net, com, edu etc. Unfortunately msnbc.net exists and looks nothing like msnbc.com ... in this case the difference is not harmful. However it opens the interesting possibility of .net domain mirrors of say schwab.com or some other financial site with the associated security implications. ------------------------------ Date: Mon, 21 Jul 1997 16:15:23 -0700 (PDT) From: Mark Durst Subject: Computer jargon enters mainstream, is hit by truck *The New York Times* Cybertimes story "Minor Error Throws Internet Into Disarray", on 18 July 1997, by the usually savvy John Markoff, contains one howler: > Computer experts said the global glitch demonstrated that even a > single point of vulnerability in the Internet's addressing system > could hamper the workings of the far-flung computer network. RISKS cognoscenti understand the term "single point of failure" to refer to the critical dependency of an entire system on one component, certainly a cause of last week's fiasco. The opposite notion is of a system that can survive failures in any specific piece. But the text gives a quite different impression with that "even", suggesting that the opposite notion would be a system with many points of "vulnerability". You "computer experts" out there: explain your buzzwords thoroughly, or RISK having your pronouncements turned inside out! Mark Durst San Leandro CA [Long-time RISKS readers will also recollect many cases in which MULTIPLE points of failures were involved. (For example, see Chapter 4 of my Computer-Related Risks.) Of course, most systems seem to have MANY SINGLE-point failure modes, and if those don't get you there are lots of MULTIPLE-point failure modes. PGN] ------------------------------ Date: Sat, 19 Jul 1997 15:21:21 +0100 From: Roger Barnett Subject: The dangers of Explorer-ation As a follow on to the other comments on the security of Web browsers, I noticed recently that several Microsoft products now use their Explorer browser as their online Help interface. However, to use this feature it is necessary to enable some, if not all, of the "riskier" capabilities such as ActiveX and Java support - otherwise the Help information is inaccessible. What chances of the user remembering to re-disable these features before venturing back out onto the big bad Internet ? Incidentally, I first hit this problem with a Sales CD issued by DEC - again, the only way to access the data on the CD was via Explorer with ActiveX and Java applet loading enabled. Roger Barnett ------------------------------ Date: Mon, 21 Jul 1997 22:52:48 -0400 (EDT) From: am676@freenet.carleton.ca (Alex Klaus) Subject: Win 95 TCP/IP Hole While searching the Microsoft web site for Win95 updates, I came across an interesting KB article. This deals with a problem with Win95's handling of Microsoft TCP/IP, according to the article when Win'95 receives an Out of Bound packet ". . . deliberately sent to the server" a Fatal Exception error will result(The blue screen of death). " An update available on the web site will fix the problem. The RISKS, if someone generates an out of bound packet, whether by accident or design " . . . the computer may not receive further network data until Windows is restarted." The full text of the article can be found at:http://www.microsoft.com/kb/articles/q168/7/47.htm A link to the patch is also on this page. vtcpupd.exe is the file name Alex Klaus ------------------------------ Date: Fri, 18 Jul 1997 17:25:00 -0700 From: pck@netcom.com (Paul C. Kocher) Subject: Re: MD5 weakness and possible consequences (Giles, RISKS-19.24) > This then becomes a matter of determining an _efficient_ way to set the > value of the MD5 (or any) hash function to a desired value. Although collisions must exist in cryptographic hash functions, this (hopefully) isn't going to be easy. In general, finding even a single example of a collision is generally considered proof that the hash function is broken. Finding a feasible way to construct messages with a desired hash would be a much more dramatic result. Cryptanalysis of hash functions is an interesting and important area which hasn't been given nearly as much attention as it deserves (though there has been some excellent work in the area, such as what what Hans Dobbertin has done attacking MD5 and MD5 -- see http://www.cryptography.com/papers/hash/dobbertin.txt, for example). The consequences of a major hash function break could be quite devastating -- virtually all certificates, digital signatures, and modern cryptographic protocols rely heavily on the collision resistance of MD5 and/or SHA... Paul Kocher, President, Cryptography Research, 870 Market St., Suite 1088 San Francisco, CA 94102 415-397-0111 (FAX: -0127) paul@cryptography.com ------------------------------ Date: Mon, 21 Jul 1997 10:50:34 -0500 (CDT) From: test acct Subject: Re: Voice-controlled MS WORD (RISKS-19.25) My cousin tried that on a Mac running 7.6. It was rather accurate, but tended to do a shutdown reboot when inspired by certain background noises [exactly what it is, we have no idea]. However, he took the machine home, to Hong Kong. Being rather tight on landspace, HK offices are very "friendly" and has a rather high ambient noise level when compared with US. As a result of that, that Mac tried to reboot every few minutes. Turned it off finally. So, I guess, risks would be trying to go overseas/unusual accents :P -Tai ------------------------------ Date: 24 Jul 1997 11:38:25 -0400 From: Christopher Kline Subject: Re: Voice-controlled MS WORD (RISKS-19.25) > "It'll make people give up the mouse," says Lernout & Hauspie's > chief technology officer. Don't bet on it. The risks of spoken interfaces are the same as those of mechanical ones. I recently saw a program on television (around two months ago; unfortunately I have forgotten the program name) wherein a company purchased voice interface systems to help stem the rise of repetitive stress injuries (RSI) that their employees were experiencing. The catch? The workers soon began experiencing voice-related RSIs. It seems that long periods of enunciating short, carefully articulated phrases ("cut cell"... "down cell"... "over row"... "paste cell") had led to damage to the employees' vocal cords and supporting anatomy. I can't wait for the brain cramps that come with neural interfaces... Christopher Kline [Various other comments also received. PGN] ------------------------------ Date: 22 Jul 97 21:09:04 +0100 From: Jonathan de Boyne Pollard Subject: Re: Medical computer crashes (Van Vleck, RISKS-19.25) Possibly, it was not a PC at all, but a mainframe or timesharing system terminal, and the nightly backup runs at midnight. In my experience, some several years ago, of one such system, the nightly backup ran at the highest priority. This meant that all terminals effectively "died" at 00:01, only to spontaneously come back to life again 5 to 10 minutes later -- the first couple of times with a sudden rush of all of the queued keystrokes that I had entered over those 5 to 10 minutes in my puzzlement. (-: The risk if this is the case? Almost certainly of using the same system administration techniques that work well for a daytime-only system (scheduling the backup to run at night because that's when no-one will be using the system) on a 24-hour system. On the other hand, one could argue that a delay in one admissions data entry is less critical than a delay in the backup of the whole day's transactions, and so it is proper that the backup run at a high priority at the expense of those interactive users unlucky enough to be active at the time. Please remove the '$' in the from line before reply via e-mail. Anti-UCE filter in operation. ------------------------------ Date: Fri, 25 Jul 1997 12:40:52 -0400 (EDT) From: driss@golden.net Subject: Y2K: a different solution One of the most difficult tasks in dealing with the Y2K problem is finding the parts of the source code or libraries that are used that are not Y2K complaint. However, what if you look at the problem from a different angle. Assuming that most of the software systems can be simplified to say there is a user or batch system layer that communicates with a database layer, what if: 1. You transfer all "live" records in the database that involve dates between 1900-1909 to a new software system. There should be few enough of these types of records that the work should be reasonable. [A live record is one that is still used. All dead records would be removed from the database and stored with a big note.] 2. You set all of the dates of data in the database back 10 years 3. You introduce a new layer in the software model. Add a program that intercepts calls that normally go directly to the database that would increase the date of data that is leaving the database (on requests or queries) and decrease the date of data that is entering the database. This would allow the user interface layer to only require an aesthetic change (displaying 20xx instead of 19xx), allow for more time to develop a more complete, revised system (allowing for better amortization on the development of such software that is most likely already in progress), reduce the cost and difficulty leave of a Y2K "solution" and be easier to track problems with as it will retain the integrity of the database and user interface layers. This could be seen as being a perpetual solution as the number of people, particularly in insurance databases, however that would require two separate systems to be running, which would not be cost effective in the long run. Driss ------------------------------ Date: Wed, 23 Jul 1997 07:02:37 -0400 From: David Chase Subject: Re: DEC Alpha Bug, final resolution (March, RISKS-19.25) > Should there be a standard (no that will never work :-) set of tests that > all chips must go through during start up? Perhaps, but at startup is not often enough unless your machine reboots frequently. Long, long ago, a Vax-11/780 at Rice University had its floating point accelerator (an entire board) go a little funny in the head without telling anyone. After that (after wondering how much of a week's worth of x-ray crystallography and reservoir simulations were junk) we decided to run user-mode floating point diagnostics late every night. Of course, I imagine most people are like me -- I use a Pentium- based machine, and haven't a clue how to run floating point diagnostics, nor do the Norton Utilities advertise that they check the FP (come on, guys, it wouldn't take long compared to checking my disk), and if I use the past to predict the future, the chip vendor won't tell me if a problem is discovered. David Chase, chase@world.std.com ------------------------------ Date: Thu, 24 Jul 1997 02:59:21 -0400 From: shri@unreal.cs.umass.edu (H.Shrikumar) Subject: Re: The truth about Usenet's Psychic Spammers! There were some serious errors in the article about the psychic spammers (800-number asks caller to dial 809 number, rip-off). And, though this instance might be simple misconception, there is a RISK of an oft-quoted forum like RISKS carrying egregious errors without a correction. >However, several foreign countries have been assigned "North American" >area codes recently. Among them, area code 809 for the Caribbean. These numbers are not a "recent assignment". In fact they are a holdover from the _past_. Some Caribbean nations were given area-codes under the North American Numbering Plan (NANP, 1947) many years before there was such a thing as country codes or even Trans-Atlantic Telephone cable (TAT-1, 1956), Exploiting these area-code-look-alikes for scams is a recent phenomenon, though. >Since these people are not bound by US law, they do not need to >disclose the full cost of making the phone call. Too many misconceptions here .. First: These calls are very much bound by US law, being billed by a US long distance company. But remember that US law is based on a "free market", so a rip-off can still be "legal". (The RISKS of govt regulated tariffs are left as an exercise to the reader.) Second: They do have to disclose the rate (fair business, fraud etc.), but you've got to ask! (e.g., the operator). What can one do ? Be alert. There are innumerable ways one may be given the number to call. From a 800-number call, Or an advt. Your beeper. You return an urgent call. You fax them. Someone "borrowed" your phone. That BBS number with "free" goodies. Almost anyhow! (Your dreams are probably safe, though, despite the 'psychics'). Look at the first few digits of the number being called. 1. 1-809- ... 2. 011- ... 3. 10-XXX-... (May be written as 1-0XX-X ... !!) If in doubt, ask your local friendly '0' operator for advice. There is another similar scam that involves the victim getting a collect call (possibly about something worrisome), but one that just "happens" to be carried by a rip-off long distance company. Ask. REFUSE A COLLECT CALL UNLESS you know (1) what telephone company it is, and (2) what the charges would be. >http://www.fraud.org/809alert.htm >http://www.oag.state.tx.us/WEBSITE/NEWS/LEGALMAT/9701cpd.htm >http://www.ece.orst.edu/~alper/Info/scam.html These web sites suggested do make an excellent read. Here are a few more authoritative sources of information. Linkname: BELLCORE: National Solutions - North American Numbering Plan (NANP) URL: http://www.bellcore.com/NANP/ Linkname: CONSUMER ALERT: International Dial-a-Porn URL: http://www.fcc.gov/ib/td/dialporn.txt Shrikumar, shri@cs.umass.edu ------------------------------ Date: Mon, 21 Jul 1997 09:22:18 -0400 From: hymie! Subject: Re: The truth about Usenet's Psychic Spammers! (Corteville, R19.25) Re: The "809" problem, it might be worth noting that the so-called "809 problem" has expanded? My telephone book lists the following area codes: 242 Bahamas 246 Barbados 441 Bermuda 787 Puerto Rico I believe an area code has been assigned to Monserrat as well, and I would expect more to be assigned to this set of countries. (And this reminds me of a recent scam where "011-24" was claimed to be the country code for Canada. It turned out that there is no country code 24, but the phone number started with 8, and 011-248 is the country code for Seychelles Island.) RISK? Naming a problem by a characteristic that turns out to be non-unique? ..hymie! ------------------------------ Date: 17 Apr 1997 From: RISKS moderator Subject: Privacy Digests Periodically I remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern. * The PRIVACY Forum is run by Lauren Weinstein. It includes a digest (which he moderates quite selectively), archive, and other features, such as PRIVACY Forum Radio interviews. It is somewhat akin to RISKS; it spans the full range of both technological and nontechnological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". PRIVACY Forum materials, including archive access/searching, additional information, and all other facets, are available on the Web via: http://www.vortex.com * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN [For privacy devotees, there was an interesting panel at the Commonwealth Club of California on Thursday night, 24 Jul 1997, entitled PRIVACY ON THE INTERNET: Who Holds the Keys? Gina Smith of ACM News moderated, with David Carlick (PowerAgent), Marc Rotenberg (EPIC), Phil Dunkelberger (PGP), Christine Varney (FTC), and me. The audio might appear somewhen on NPR, and CCC audio is rumored to be archived somewhere on cnet.com.] ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.26 ************************