precedence: bulk Subject: RISKS DIGEST 18.79 RISKS-LIST: Risks-Forum Digest Tues 28 January 1997 Volume 18 : Issue 79 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: Spamming Risks and Solutions (Simson L. Garfinkel) Risks of floor repair (Paul Bissex) Computer Glitch Gives Investors Instant Loss of Balance at Schwab (Norm deCarteret) Microsoft Office 97 Steals My Initials, MSOF (Michael S.O. Franz) Cosmic radiation can cause computer memory loss (Martin Minow) Re: Shetland Times copyright suit (Prabhakar Ragde, John Pelan) Re: Macintoshes and Y2K (Bear Giles, Jonathan Stott) Y2K on non-Unix/Microsoft systems (Steve McKinty) Re: Y2036, Y2038, and the superiority of UNIX (Frederick G.M. Roeber) URL filtering, Re: ad.doubleclick.net (Caveh Frank Jalali) Guilty by confusion? Domain names and IP addresses of net.abusers (Lars Wirzenius) Adios ads.doubleclick.net (John Hascall) Side benefit of proxies re cookies (Mark Seecof) Risks of communicating with the wrong person (James W. Birdsall) E-Mail Addressing Problems (Todd Burgess) Verifying Mail Addresses (David Fetrow) AOL software flaw (JMFBAH) 4th ACM Conference on Computer and Communications Security (Mike Reiter) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 20 Jan 1997 20:30:41 -0800 From: "Simson L. Garfinkel" Subject: Spamming Risks and Solutions On Monday, 13 Jan 1997, Vineyard.NET was apparently attacked by a spam-for-hire company. The organization, "CV Communications," connected to our SMTP server and started sending us advertisements for its own spamming services. I discovered the attack after approximately 66,000 messages were sent. Most of them went to subscribers of AOL and CompuServe. I contacted the spammer, using the phone number at the bottom of each message he was sending out, and demanded that he stop. Spamming is a known problem on the Internet. I'm hopeful that law-enforcement agencies will start seriously looking into this problem, as I think that there is a limit to how effective technological solutions can be. However, there are several solutions that I have thought of. 1. Limit the number of RECV recipients permitted in each SMTP transaction. Rather than sending out tens of thousands of messages, we were hit with a few hundred messages that each had more than 100 recipients. We have therefore modified our netperm-table file to limit the number of recipients that each SMTP connection can have. 2. Disallow transiting. Vineyard.NET's SMTP server is used both by our customers to send out messages and by others on the Internet to send us messages. But it shouldn't be used by others on the Internet to send messages through us to third parties. We have therefore modified our SMTP server so that it can tell the difference between an internal connection and an external connection. External connections are not allowed to transit through us to other external mail servers. 3. Reject messages that come from "suspicious" sources. We have not implemented this yet. However, it seems reasonable to reject out of hand any SMTP message from certain kinds of hosts. For example, you might want to reject those from addresses that do not have a valid domain name, or from hosts that appear to be dialup addresses. I have written an article about this spamming incident which will appear in my 28 Jan 1997 Packet column. You can view it at http://www.packet.com/garfinkel on Wednesday January 29th. I have also made my modified SMTP server available. It is located at http://simson.vineyard.net/hw/spam2/smap.c . This is a modified version of the Trusted Information System's SMAP server, part of their firewall toolkit. It is my understanding that FWTK is no longer being maintained by TIS, which is a pity. Simson L. Garfinkel, Visiting Scholar, University of Washington, Columnist for PACKET and The Boston Globe. ------------------------------ Date: Sat, 25 Jan 1997 13:14:16 -0800 (PST) From: pb@well.com (Paul Bissex) Subject: Risks of floor repair Last summer, contractors at Commonwealth Edison's LaSalle nuclear power station were filling cracks in a concrete floor by pumping them full of foam grout. What the workers didn't know, though, was that a tunnel ran beneath that floor, carrying water for some safety systems at the plant, and their grout was pouring through the cracks into the water. The grout partially clogged the tunnel, compromising safety at the plant for 10 days before Edison -- when pushed by federal inspectors -- finally figured out what was wrong. [*Chicago Tribune*, 25 Jan 1997, front page] The NRC levied a $650,000 fine for what they called a "very significant safety problem." Without getting into a debate about nuclear power, I think one could point out the risk in thinking that there are any non-critical jobs where critical systems are concerned. Paul Bissex pb@well.com http://www.well.com/user/pb/tech/ [Grout, Grout, Dammed Slot! PGN] ------------------------------ Date: Thu, 23 Jan 97 08:06:05 EST From: "Norm deCarteret (813-878-3798 (TL 438)" Subject: 'Computer Glitch Gives Investors Instant Loss of Balance at Schwab' A program error caused Schwab's computers to omit a significant number of mutual funds when investors used Telebroker to track holdings by phone, leading some of them to believe themselves broke. The problem existed from Monday afternoon through late Tuesday evening scaring scores of investors. Janus, Putnam and Schwab's own funds were among those omitted from net asset calculations. Tracey Gordon, Schwab spokeswoman: "We were making some system changes when there was a program error." On why the problem went on so long: 'Mutual funds are priced once a day. We found that it would be cleaner and simpler to wait until the next regularly scheduled market change to update the system'. Cleaner and simpler for Schwab, presumably. Gordon said investors who made panicky trades as a result 'would be made whole' but there'd be risks in determining both the who and the how much. Norm deCarteret ------------------------------ Date: Wed, 22 Jan 1997 15:56:04 -0800 From: Michael Franz Subject: Microsoft Office 97 Steals My Initials, MSOF My full name is Michael Steffen Oliver Franz, which makes my initials "msof". I usually use these initials in internal correspondence, and I have an e-mail address "msof@sprynet.com". Now, I just installed Microsoft Office 97 on my computer. Curiously, Office 97 automatically replaces some occurrences of "msof" by "Microsoft Office". For example, this happens in the "initials" box in the Word Annotations dialog. I am not yet sure how far-reaching this automatism is, but the prospect of having my name replaced without my knowledge is frightening. You can see this strange effect for yourself if you type "msof" at the start of a line in Word and then wait for a short time. Michael Steffen Oliver Franz franz@uci.edu (university business) and msof@sprynet.com (private) ------------------------------ Date: Fri, 24 Jan 1997 10:08:38 -0800 From: Martin Minow Subject: Cosmic radiation can cause computer memory loss An article in the Swedish newspaper Svenska Dagbladet (1997 Jan 24) currently available on their web site http://www.svd.se/ describes research carried out by Ericsson Saab Avionics by Karin Johansson that suggests that computers, especially those carried on high-altitude aircraft flights, may be at risk for cosmic radiation. Johansson and her colleagues carried out experiments on SAS transcontinental (Atlantic) flights that measured one [bit] error per memory chip per 200 hours. The article notes that a modern personal computer may have 64 such chips. This means that an ordinary laptop PC may expect an error every three hours, or about twice during an atlantic flight. [Assuming you brought enough batteries.] The problem is worsened when the flight path is over the North Pole because the earth's magnetic field, which normally protects against cosmic radiation, is directed such that the protection is lessened. Karin Johansson notes that the computers used to control the aircraft itself "are not the absolutely most modern, and consequently their electronic circuits are not as small and sensitive." However, component manufacturers are not interested in building electronics for such a small market as avionics, so the aircraft manufacturers must use the electronics available in the marketplace. To protect against error, aircraft computer designers will use parity and error-correcting circuitry to prevent a single-bit error from propagating into other computation. Summerized and translated by Martin Minow, minow@apple.com ------------------------------ Date: Fri, 24 Jan 1997 09:51:35 -0500 (EST) From: Prabhakar Ragde Subject: Re: Shetland Times copyright suit (Randell, RISKS-18.78) The Shetland Times has obtained a preliminary injunction against the Shetland News to prevent the News's web site from linking to Times documents. Part of the judge's reasoning was that the advertising material on the "front page" of the Times could thus be bypassed. I did an AltaVista search on the phrase "Shetland Times" and came up with lots of links into the depths of the Shetland Times site. Presumably DEC has committed the same offense as the Shetland News, and their new European mirror site might be vulnerable to a similar challenge. Given the usual response to any attempts to remove "offensive" or "illegal" material from the Net, I'm surprised that I didn't turn up dozens of third-party links into the Shetland Times site, in defiance of the reasoning behind the injunction. Prabhakar Ragde, Department of Computer Science, University of Waterloo Waterloo, Ontario CANADA N2L 3G1 (519)888-4567,x4660 plragde@plg.uwaterloo.ca [There were several longer messages with similar points. PGN] ------------------------------ Date: Thu, 23 Jan 1997 20:18:45 +0000 (GMT) From: John Pelan Subject: Re: Shetland Times copyright suit (Randell, RISKS-18.78) The judgement, as I believe it should be interpreted, means that it is the duplication of the headlines themselves which breached the copyright law. Whether they link to the original Shetland Times articles or different articles on the same story is irrelevant. The judge believes that the headlines constitute a separate work. It think that his decision was in line with the intention and spirit of the copyright law. Also, I note that RISKS contributions with URLs seem to be increasingly giving away the registered account information, namely http://www.the-times.co.uk/news/pages/tim/97/01/21/timlawscl01001.html?10695 This contains '10695' at the end, which is what identifies the user and now permits anyone to access The Times site in that guise. Watch out for a change in personal preferences ! John Pelan (J.Pelan@qub.ac.uk) [Note, in the above the '10695' is in fact a truncation of the full set of digits that were in the URL that Brian had posted. In a side message, Brian recommends that in the future that he/we indicate when such alterations are made. PGN] ------------------------------ Date: Thu, 23 Jan 1997 19:20:43 -0700 (MST) From: Bear Giles Subject: Re: Macintoshes and Y2K (Wood, RISKS-18.78) >Macintosh users probably have less cause for concern about the year 2000 >than any other computer users, thanks to Apple's farsighted programmers. This gem illustrates just how nasty the Y2K issue is. The internal representation of the date is only one small Y2K problem. The others include: - are the library functions robust? Are they correct? (E.g., can they tell you whether 2000 is a leap year? The date of Memorial Day in 2017? The date of Easter in 2004? The number of business days between any two arbitrary dates?) - do the developers actually call these functions, or do they write their own? - do the developers always display 4-digit years? If not, do they always truncate the year correctly? - do the developers alway require 4-digit years? If not, how do they interpret shorter years? Bottom line: if mac programs are intrinsically Y2K safe due _solely_ to the representation selected by the godlike system designers at Apple, then all C++ programs are intrinsically bug free and fault tolerant since that language was designed to include resources to help make software engineering manageable. Bear Giles bear@indra.com ------------------------------ Date: 23 Jan 1997 17:58:56 GMT From: RFC822@poly.phys.cwru.edu (Jonathan Stott) Subject: Re: Macintoshes and Y2K (Wood, RISKS-18.78) Ahh, but how do your _applications_ store dates? If only the last two digits are stored on disk then you have a problem, no matter how many bits your system clock uses. Good hardware design only provides a false sense of security when the programmers get sloppy. Jonathan Stott, CWRU Dept. of Physics, School of Graduate Studies jjs17@po.cwru.edu jstott@poly.cwru.edu http://poly.phys.cwru.edu/~jstott/ ------------------------------ Date: Thu, 23 Jan 1997 15:05:49 +0100 From: smckinty@sunicnc.France.Sun.COM (Steve McKinty Sun Microsystems Grenoble) Subject: Y2K on non-Unix/Microsoft systems (Wood, RISKS-18.78) This isn't particularly novel. DEC's VMS operating system (designed in the mid-1970s) also implements the date as a 64-bit signed integer giving the number of microseconds since the Smithsonian base date of (I think) 17th November 1858. +ve numbers are regarded as absolute values, -ve ones as deltas, but even so the VMS clock is good for many millenia. In addition to that all date displays use a 4-digit year. There is a well-known bug filed against VMS pointing out that the date displays will be incorrect after Dec 31st 9999. The bug was accepted by DEC with the note "we will fix this in a future major architecture." Steve ------------------------------ Date: Fri, 24 Jan 1997 01:57:37 -0800 From: "Frederick G.M. Roeber" Subject: Re: Y2036, Y2038, and the superiority of UNIX (RISKS-18.78) In RISKS 18.78, Dan Hicks wrote: > I prefer a floating-point format ... Note that if you are measuring intervals by subtracting timestamps, then the use of floating point numbers for the timestamps can lead to hard-to-debug errors in accuracy. The Patriot missile failure in Dhahran was caused by a similar error: values from the system clock (integer number of tenths of seconds since powerup) were converted into floating point values to do the intercept math. After some number of days of operation, the point floated, and the accuracy suffered. [See RISKS-13.35] While it can be argued that this merely means that intervals should not be measured by subtraction like this, I think that floating-point system clocks would only increase the RISK of such an error. Frederick G.M. Roeber, Netscape Communications Corp., 501 E. Middlefield Rd. Mountain View, CA, USA-94043 +1 (415) 937 3180 roeber@netscape.com ------------------------------ Date: Thu, 23 Jan 1997 14:15:38 -0800 From: Caveh Frank Jalali Subject: URL filtering, Re: ad.doubleclick.net (RISKS-18.78) The obvious defense against hostile or undesirable web sites is to not visit them in the first place. This process can in fact be automated in netscape's browser. This saves bandwidth and your time! The basic premise is that the browser may optionally execute a function on every URL before it is accessed to determine whether a direct connection should be made or a proxy should be used in the process. This affords the opportunity to [mis]direct the browser to fetch the document from an invalid source. this is a good approximation of not getting the document at all. We sit behind a fire wall, so all WWW access has to funnel through a proxy. If I tell netscape to fetch an external document using a direct connection, the connection attempt will fail, and the document will not be accessed. Netscape will put a broken image icon in its place. Here are the nuts and bolts to do it, but some assembly is required: Under options/network preferences/proxies, select "automatic proxy config" and tell it which file to use. Call it something like "file:///HOMEDIR/.netscape/proxy.pac", replacing HOMEDIR with your home directory; the actual code is included below. Next, go to options/general preferences/helpers and create an application helper of type "application/x-ns-proxy-autoconfig" for suffix "pac", handled by "navigator". Install this java-script code to do the actual filtering. call it "file:///HOMEDIR/.netscape/proxy.pac", as mentioned before. ================ function FindProxyForURL(url, host) { if ( isResolvable(host) && ! shExpMatch(host, "[0-9]*") ) return "DIRECT" ; else if (host == "advertising.quote.com") return "DIRECT" ; else if (host == "ad.doubleclick.net") return "DIRECT" ; else if (shExpMatch(url, "*:*/ads/*")) return "DIRECT" ; else return "PROXY webcache:8080; "; } ------------------------------ Date: Thu, 23 Jan 1997 12:08:32 +0200 From: Lars Wirzenius Subject: Guilty by confusion? Domain names and IP addresses of net.abusers Net.abuse (spamming, mailbombing, systematic trolling, etc) are being fought via filters, among other things. This leads to unexpected risks for innocent bystanders. Having a similar domain name as a known net.abuser can make you guilty by confusion: if a spammer operates from earthFOO.com, and you are earthBAR.com, people are going to confuse the two domains. This has already happened (for suitable values of FOO and BAR -- the common earth prefix was actually used). If it happens in a discussion, it can be (and has been) corrected. If it happens in a router, filter, or other software, it can be difficult to even detect. A similar thing applies to IP numbers. Many sites now block all IP addresses belonging to problematic sites. If at a later date those addresses are reclaimed by the ISP and re-assigned to another client, that client will still be blocked. Given the worries about IPv4 numbers running out, especially for smaller ISPs, this isn't unthinkable. I have an aggressive junkmail filter (http://www.iki.fi/liw/mail-to-lasu.html) You don't have to worry about it, since I've sent you mail. ------------------------------ Date: Fri, 24 Jan 1997 11:29:38 -0600 From: John Hascall Subject: Adios ads.doubleclick.net I put the following in my /etc/hosts (yea, unix-centric, too bad): 127.0.0.1 localhost ad.doubleclick.net End of problem. I suppose if not already running a WWW server one could even put in a simple script invoked by inetd : #!/bin/sh echo "Content-type: image/gif" echo "" cat /usr/local/etc/nyah-nyah-nyah.gif if it makes you happier.... I suppose the risk is if ad-avoidance becomes popular enough that browser makers make it easy, then everyone does it, then an unintended consequence might be the hastening of the "pay-per-viewing" of the internet. John ------------------------------ Date: Fri, 24 Jan 1997 18:03:30 -0800 From: Mark Seecof Subject: Side benefit of proxies re cookies A side benefit of proxy-server/firewalls is that they somewhat mask the identity of web-browsing folks behind them. When I refuse cookies and access Internet resources through the firewall of a large organization I get much of the anonymity I might want. I suggest that ISP's should offer to proxy their small customers' browsing just to give them this benefit. ------------------------------ Date: Thu, 23 Jan 1997 20:19:11 -0800 From: "James W. Birdsall" Subject: Risks of communicating with the wrong person Actually, the risks of misaddressing occur in any communication medium. We all receive paper mail that isn't for us; since most of us check addresses before opening mail, privacy is usually preserved at least (as it would be if we used the electronic equivalent of envelopes -- encryption). We all receive phone calls that aren't for us; since the telephone is an interactive medium it is customary to verify the identify of the person at the other end before exchanging messages, thus preserving privacy and ensuring that the message reaches the right person. In 18.77, darin@connectnet1.connectnet.com (Darin Johnson) writes: >The old rule applies - never say anything on usenet or e-mail that you >wouldn't mind being posted in the office lunchroom. Chances are, it just >might end up there. Actually, the place where this event is most common is on the MU* (MUD, MUSH, MUCK, MOO, MUX, etc.) systems, where it is known as a "mav". When sending a private message (page, whisper) to someone, it is very easy to 1) send a message to the wrong person, typically somebody else you are talking to or 2) mistype the command so everybody in the room sees the message. On fancier systems which allow a user to automatically reply to the last person who paged them, it is common (especially when the net is lagging) to get a page from person B while typing a reply to person A and thereby accidentally send the reply to person B. Despite a lot of fallout and embarrassment from these incidents, nobody has come up with a good way of reducing them -- if people won't double-check what they type, there's nothing software can do to save them. Also in 18.77, Lawrence.H.Smith@williams.edu (Lawrence H Smith) writes: > ... naive users perceive it as "like paper mail, only faster and cheaper" - > a perception which is deeply flawed. Actually, the perception that paper mail is reliable is deeply flawed. Comparing the performance of the US Postal Service to that of the net in my nine-plus years on the net, I would have to say that paper mail is at least as bad if not worse. The post office loses several pieces of mail on me every year. Their latest goof-up was to misdeliver a piece of mail to the wrong address (wrong *state*, even!) three times before bouncing it back to me. Now, this failure mode is shared by electronic mail, but the post office took two months as opposed to a few hours. --James W. Birdsall ------------------------------ Date: Thu, 23 Jan 1997 23:07:10 -0500 (EST) From: Todd Burgess Subject: E-Mail Addressing Problems The university of Guelph has a simple policy for creating e-mail accounts: first initial, last name (i.e., tburgess@uoguelph.ca). This scheme works great as long as their are no duplicates (ie Tom Burgess). If there are duplicates then they start adding numbers to the e-mail ID or simply using first names. When my brother came to Guelph my Dad tried sending e-mail to jburgess@uoguelph.ca which was not my brother's e-mail account. My brother had been given the account joel@uoguelph.ca. Luckily the person who got the e-mail was nice enough to look up the correct address and forward it to my brother. The RISKs? E-mail ID schemes like this work great as long as there are no duplicate names. The moment there are duplicate names then a lot people are going to start seeing other people's e-mail. As for Kamens's (RISKS 18.78) comment about paper mail vs. e-mail. I think it would be fair to say that it is easier to get an e-mail address wrong then a paper address wrong. E-mail delivery systems only have the e-mail address to go on when delivering mail. If your e-mail ID doesn't match then tough it bounces. Mail addresses have fields like name, address, city, country and postal code to assist in delivering mail. Failing that post offices can open mail in hopes of finding the correct address. I know people who have worked in post offices in small towns and they say they can usually determine where to send a letter simply on the name alone (even if the address is incorrect or missing). University of Guelph, Computer Science Major E-mail: tburgess@uoguelph.ca URL: http://eddie.cis.uoguelph.ca/~tburgess ------------------------------ Date: Fri, 24 Jan 1997 21:26:55 -0800 (PST) From: David Fetrow Subject: Verifying Mail Addresses In RISKS-18.78 Mike_Perry@DGE.ceo.dg.com and others discuss the problem of verifying e-mail addresses as correct, rather than just hitting the send key. The obvious solution ("Do you really want to send this? y/n") would undoubtably work no better than it does for file deletion. It occurred to me that perhaps what's needed is verifying something besides words on the screen; that if I am dealing with two kinds of sensory data something is more likely to click. e.g. a voice saying: "Sending mail to Ann Landers , OK?" and my saying "yes" or "no" (well within a modern machines abilities). Perhaps even do a little scan for hot words and have it ask: "Do you really want to use the word 'braindead' in your mail to 'boss'?". Although this is probably silly regarding e-mail (and adds a host of risks of its own) such warnings attached to particularly risky commands and forcing a person to do something *unusual* to continue could prevent a lot of errors, if not overused. (Note, something similar happens when the WinNT 4.0 license appears on the screen while installing that product. To continue you have to hit F8, and only F8. You are pretty much forced to at least glance at the license in order to continue. Annoying but rather slick. Taking it one step further: the key could needed could be chosen at random from the non-letters.) David Fetrow, Biostatistics, University of Washington ------------------------------ Date: Thu, 23 Jan 1997 09:30:15 -0500 (EST) From: jmfbah@aol.com (JMFBAH) Subject: AOL software flaw (Re: PGN comment in RISKS-18.77) > ... AOL seems to have shot itself in the foot by going to flat-rate charges. Complicating the access problem (which I haven't experienced personally) is that AOL keeps putting up a piece of software that seems to block internet traffic. Despite repeated attempts to explain the problem, this software still appears (almost every other day) without the original problems getting fixed. I believe it's very hard to determine whether the new pricing has anything to do with their problems as long as they keep putting up software that doesn't work. /BAH ------------------------------ Date: Thu, 23 Jan 1997 22:03:33 -0500 (EST) From: Mike Reiter Subject: 4th ACM Conference on Computer and Communications Security *** EARLY REGISTRATION DISCOUNT ENDS JANUARY 31 *** Fourth ACM Conference on Computer and Communications Security (Preliminary Technical Program) Zurich, Switzerland April 1-4, 1997 Sponsored by ACM SIGSAC For more information, including registration and hotel information, see: http://www.zurich.ibm.ch/pub/Other/ACMsec/index.html [The program looks really interesting. PGN says, "check it out."] ------------------------------ Date: 15 Aug 1996 (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 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 18.79 ************************