precedence: bulk Subject: Risks Digest 20.40 RISKS-LIST: Risks-Forum Digest Tuesday 18 May 1999 Volume 20 : Issue 40 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. ***** This issue is archived at and at ftp.sri.com/risks/ . Contents: Nuclear plant Y2K: High risk-readiness or high-risk readiness? (Mike Perry) Biometric risks (Dan Wallach) Singaporean ISP scans users' PCs (Andrew Brydon) ATMs gobble up cash cards (John Colville) Web browsers, URL collisions, and all that... (Zygo Blaxell) False Viruses (Thomas Gilg) HotMail is no Early Bird: happy99.exe (Malcolm Pack) Virus cleaner corrupts e-mail database (Diomidis Spinellis) MIME-Messages: quoted-printable chars in URLs (Christoph Conrad) New-fangled petrol pumps (Ian Chard) Re: C compilers vs editors: WYSI NOT ALWAYS WYG (Roy O. Wright) Re: Wrong e-mail address (Andrew J Klossner) Re: Risks of 3-letter user IDs (Thayne Forbes) Dimwitted naughty-word filtering lives... (Daniel Rutter) REVIEW: "Removing the Spam", Geoff Mulligan (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 17 May 1999 16:05:42 +0100 From: "Perry, Mike" Subject: Nuclear plant Y2K: High risk-readiness or high-risk readiness? I read this last week on Silicon.com's news site (http://www.silicon.com): A US nuclear plant has received a warning from the Nuclear Regulatory Commission (NCR) after fears were raised over the Y2K readiness of an emergency backup generator. Massachusetts Congressman, Edward Markey, said the NRC has written to the Pilgrim nuclear plant expressing concern that the generator will not be able to keep the facility safe in the event of a Y2K blackout. The plant's owner said the problem will be solved by adjusting the temperature limit for the generator. Well, that's alright then, I don't suppose that the temperature limiter serves any valid safety purpose, nor that running it outside the limits prescribed by the manufacturers carries any RISKs.... Mike Perry Data General Ltd ------------------------------ Date: Fri, 14 May 1999 14:51:51 -0500 From: Dan Wallach Subject: Biometric risks Bank United of Texas has said they're about to introduce retina scanners to authenticate their customers to an ATM [1]. No more PINs. No more plastic cards. The article says they'll be using technology from Diebold, although no such technology is described on Diebold's Web page [2]. RISKS readers should be well aware that there are three different kinds of authentication (something you know, something you have, or something you are), and relying strictly on any one is a recipe for disaster. A particular concern with purely biometric authentication systems is that there's no way to revoke your retina and get a new one. If somebody manages to make a copy, you're out of luck. Says the article: "In response to questions about privacy concerns, Bank United said the iris pictures will not be distributed to anyone outside the bank." Naturally, this is deeply unassuring. Even assuming we don't have bad guys going around cutting out people's eyes, and even assuming the ATM vendor is smart enough to verify the eye has a pulse (i.e., it's still connected to its owner's head), there isn't a whole lot preventing some other vendor from photographing your iris and using your biometric against you. Also from the article: ``It has a very high cool factor,'' Coben said. ``We think of it as James Bond meets stocks and bonds.'' Hopefully, Bank United will have a golden eye for detail, and will never say never again to poor authentication. I wouldn't want my optometrist, Dr. No, to have a view to a killing in ATM crime. Dan Wallach, Rice University [1]http://dailynews.yahoo.com/headlines/ap/technology/story.html?s=v/ap/19990514/tc/atm_eye_scanners_5.html [2]http://www2.diebold.com/products/diebatms.html [This message is clearly not just for YOUR EYES ONLY, but should scare THE LIVING DAYLIGHTS out of others as well. However, with potential eye damage from miscalibrated units, remember that YOU ONLY LIVE TWICE (pronounced "TWO-EYES"). With all this Bonding going on, there must be a SCAN-DOLL in there somewhere. PGN] ------------------------------ Date: Sat, 15 May 1999 07:09:50 +0100 From: Andrew Brydon Subject: Singaporean ISP scans users' PCs Daily Telegraph (UK) Thursday 13th May 1999 - Connected (IT pullout) p.2 Singaporean Internet provider SingNet has apologised to its subscribers after scanning their PCs without their knowledge. SingNet asked the Singaporean Home Affairs Ministry to help check the computers of its 200,000 subscribers in the wake of the damage caused by the CIH virus. Unfortunately for SingNet an anti-hacking program being used by a customer picked up scanning, which was reported to the police. The scan was traced back to the government. The company says it did not look at any confidential files but did find that 900 subscribers have virus- infected computers. Andrew Brydon, Systems & Software Safety Analyst ------------------------------ Date: Mon, 17 May 1999 09:16:37 +1000 From: John Colville Subject: ATMs gobble up cash cards >From AAP via Sydney Morning Herald, Monday may 17, 1999, p4 with insertions by JC in [ ]. Many St George Bank [Australia's fifth largest bank] customers were left short at the weekend when automatic teller machines gobbled up their cash cards as the bank installed a new computer system. The bank refused to say how many customers lost their cards. [The bank probably do not know how many cards were 'gobbled' yet because they were closed from their normal Saturday morning trading in preparation for the changeover.] A spokesman said the problem occurred because of the expiry dates on certain cards. Canberra resident, Mr Steve Pye, who lost his card on Saturday, said there would be no replacements until Wednesday for "people like me with no money in my pocket . . . "I'm as mad as hell about it." John Colville, University of Technology, Sydney Broadway, NSW, Australia, 2007 colville@socs.uts.edu.au +61-2-9514-1854 ------------------------------ Date: 16 May 1999 04:05:45 -0400 From: uryse0d5@umail.furryterror.org (Zygo Blaxell) Subject: Web browsers, URL collisions, and all that... This happened to me the other month: an interesting interaction between two convenience features in web browsers and operating systems. Where I work there is an internal server (let's call it 'qqq') that maintains some data used by the group I work in. The machine generates test data and serves dozens of report pages all hyperlinked together and accessible via a web client. Because it's on a corporate intranet, all desktop machines that can access the server happen to be configured such that they are able to use the short version of the server's name, rather than the long version of the name. So instead of typing "qqq.example.com", users can just type "qqq" and the client's OS configuration for DNS lookups will find the right host. This is a convenient, time-saving feature. On the public Internet, by contrast, there is a widespread convention for a web server owned by "The Example Corporation" to be named "www.example.com". No doubt this convention was influenced by Netscape's decision to automatically expand bare hostnames typed into the "Location" field by prepending "www." and appending ".com". So instead of typing "www.example.com", a user can just type "example". This is a convenient, time-saving feature. Some months ago, the nameservers here at my employer were slightly amnesic, and kept forgetting the DNS entry for our server. So some mornings we would type 'qqq' into the Location: field of Netscape, and we would get "server does not have a DNS entry," because neither 'qqq' nor 'qqq.example.com' nor 'www.qqq.com' existed. Although Netscape only reports 'qqq' in the dialog, it does report the other names it tries in the status bar. This is mostly harmless. One day, somebody set up a web site under the name 'www.qqq.com'. From then on, whenever my employer's DNS server forgot the IP address of 'qqq.example.com' but could find 'www.qqq.com', Netscape would decide that when I typed 'qqq' I must have meant 'www.qqq.com', since neither 'qqq' itself nor 'qqq.example.com' exist, and would proceed with its request using the new host name. To make matters worse, Netscape can sometimes do this even after it has already done the DNS lookup on the host name. If this happens at just the wrong time, it means that the remote system with the similar name gets all the information we would have sent to our own server: names and passwords used to authenticate with the local server, any cookies set by programs on the server, and usually a few user ID's and file names in the URLs. If our clients were point-of-sale terminals, this data could have included everything from credit card numbers and purchase details to complete credit histories from applications for financing. Interestingly enough, this problem never happened at one of my former employers, which has a different policy for corporate host names. They insist on naming all hosts according to a company-wide encoding system that includes machine type, function, location, partial encoding of the IP address, and a check digit, which results in tens of thousands of machines with host names like "n3rndghh" or "amhjrxml". To date I know of nobody who has ever registered the domain name "www.n3rndghh.com", nor any other .com domain name that is valid in the scheme used by my former employer, so there have probably been no such collisions to date (although of course it's always possible to cultivate one). Zygo Blaxell, Linux Engineer, Corel Corporation. zygob@corel.ca (work) or zblaxell@furryterror.org (play). ------------------------------ Date: Mon, 17 May 1999 15:08:59 -0700 From: "GILG,THOMAS J (HP-Corvallis,ex1)" Subject: False Viruses When the Melissa virus hit, everyone in our R&D software lab updated their virus checkers and went into inoculation and quarantine mode. Several weeks later, I tried to run one of my old utility applications written in Microsoft Visual Basic (VB) and compiled into a .exe, and it was suddenly flagged as a "Backdoor.Trojan" virus. While the UNIX & Java in me saw great humor in it, I was no longer able to run a useful app. Debugging the situation, I found that some function calls from a VB app into a Visual C++ COM object resulted in some VB .exe code that looked like a virus. Changing the type, order and number of parameters in a function call and/or changing the location from which the function call was made would influence whether or not the resulting .exe looked like a virus. For those interested, I spent most of my time reproducing the problem with: .idl: ... HRESULT test([in] BSTR foo, [in] int bar) .h: STDMETHODIMP(test)(/*[in]*/ BSTR foo, /*[in]*/ int bar) .cpp STDMETHODIMP MyClass::test(BSTR foo, int bar) .bas mc.test "Hi", 2 I reported the problem to the virus checker company, and they confirmed some "false detection" cases. Fortunately for both of us, their latest virus definition update contained a fix for this problem. Unfortunately for some other folks in our lab, they ran into the same false virus alert with their VB apps and they removed them without question. Clearly viruses and the code to detect them are getting extremely complex, so the opportunity for false alerts will do nothing but rise. It also occurred to me that the publication of false alert notices has its own set of risks. Thomas Gilg, R&D Software Engineer, Hewlett-Packard thomas_gilg@hp.com ------------------------------ Date: Sat, 15 May 1999 08:57:59 +0100 From: mpack@email.com (Malcolm Pack) Subject: HotMail is no Early Bird: happy99.exe A colleague at work was browsing his personal e-mail on HotMail, and asked me innocently if I knew what "HAPPY99.EXE" was, since someone he knows had sent it to him as an attachment. I explained that it was a "worm", and he should: o Delete it in situ, rather than download it. o Inform the sender of their infection. o Point them at a URL with suitable removal instructions[0]. o Advise them to contact other people they might have e-mailed recently and warn them of the worm, etc.[1] He also elected (belatedly) to run HotMail's live Virus Scan, ostensibly an implementation of NAI's McAfee, over the attachment. It reported nothing amiss. Note that locally-running versions of McAfee Virusscan will correctly identify the worm as W32/Ska.exe. I have requested an explanation from HotMail, and will forward what I receive. In the meantime, trust no one[2]. [0] Interestingly, an Infind search for sites referencing "HAPPY99" turned up one personal site which offered for download an executable to effect removal. I naturally chose to ignore this program of unknown provenance. Oh, how the risks mount up. [1] So we have a whole series of legitimate e-mail warnings flying around in competition with the hoax e-mail warnings flying around and the warnings to ignore the hoax e-mail warnings flying around and... [2] Especially if his initials are BG, and his company creates operating systems which are virus-friendly[3], but owns an on-line mail system which seemingly fails to spot those same viruses. [3] And publically blames anti-virus software for a third of all crashes of its most "robust" OS. Malcolm Pack ------------------------------ Date: Tue, 18 May 1999 11:39:59 +0200 From: Diomidis Spinellis Subject: Virus cleaner corrupts e-mail database I was told the following story by an associate who is managing a large distributed IT installation. The administrators at one site installed an anti-virus product on a machine running the Microsoft Exchange e-mail server. Exchange keeps all incoming mailboxes in a monolithic database of a proprietary format. The administrators enabled a parameter of the virus scan program to automatically clean the virus-infected files. The virus scanner detected an instance of the CAP macro virus in a mail attachment WITHIN the Exchange database and proceeded to "clean" the file by performing an in-place modification on it. As a result the database was corrupted, users could not access their mail, and subsequent attempts to repair the database using the facilities provided by Exchange failed. Eventually the database was recovered from a backup resulting in lost e-mail messages. There are many lessons that can be drawn from this story; I would like to emphasise the risks of proprietary, opaque, or gratuitously complicated file formats such as those used by Microsoft Word documents, and the Exchange database. Architecting and implementing an efficient, extensible, and functional file format and interface can be difficult and expensive. However, the cost is most cases justified the resulting robustness, openness, usability, and extensibility of the system. Diomidis Spinellis, University of the Aegean ------------------------------ Date: 17 May 1999 07:19:56 +0200 From: Christoph Conrad Subject: MIME-Messages: quoted-printable chars in URLs Recently I made a request for an X509-certificate. The certification authority (CA) mailed me an URL for fetching my certificate, but it didn't work. It looked like ([...] parts are omitted by me): http://[...]CertIdentifierW746 So I wrote back to them and they answered that the last five digits are five seven seven four six, before the equal sign. I realized that this is a problem with MIME quoted-printable handling. The real URL was: http://[...]CertIdentifier=57746 "=57" is also a quoted printable char and means "character with value 0x57", this is a 'W'! christoph.conrad@post.rwth-aachen.de ------------------------------ Date: Thu, 13 May 1999 21:50:38 +0100 (BST) From: Ian Chard Subject: New-fangled petrol pumps I filled my car up with petrol today with one of these new-fangled petrol pumps that lets you stick your credit/debit card in, fill up you car and then drive away without having to queue up in the shop. I didn't really trust the pump (and I thought the poorly trained staff might think that I was just driving away without paying), so I asked it for a receipt. I reached under the pump (where the printer is), grabbed the receipt, and drove away. When I got home, I fished the receipt out of my pocket, and it struck me that the 28 quid I had been charged was rather more than my car could hold. "Hmm," I thought, "maybe the prices have gone up". I then noticed that the card type was "MASTERCARD", which I don't have. "Hmm," I thought, "maybe it just represents Switch (my card type) as Mastercard. Then I noticed that the first digit of the (full) card number on the receipt was a 5, whereas mine was a 6. Then the penny dropped. The printer took rather longer than I thought to print the receipt. What I got was someone else's receipt, with their full credit card number and expiry date. To my horror, I also realised that the next customer will get my card number and expiry date. Alas, it was now 30 minutes later, and my details are almost certainly in someone else's pocket. The RISK here is not only that old adage about not printing the full card number when the last five digits will do. I wouldn't have had a problem if the thing had said "PRINTING PLEASE WAIT". What it did say was "PLEASE TAKE RECEIPT FROM BELOW PUMP". I looked, saw a piece of paper, and took it. Ian Chard, Sheriffmuir +44 976 249081 http://www.tanagra.demon.co.uk ------------------------------ Date: Mon, 17 May 1999 17:02:06 -0500 From: "Roy O. Wright" Subject: Re: C compilers vs editors: WYSI NOT ALWAYS WYG (Graifer, RISKS-20.39) In MS Visual J++, Microsoft will sometimes use a single carriage return as a line terminator. As pointed out by Daniel Graifer, this can introduce bugs when moving the source code to a different compiler - EVEN ON THE SAME PLATFORM (ex. Semantic's Visual Cafe and the Sun's Java SDK on MS Windows) This looks like either an attempt to lock a developer into one set of tools or very sloppy design. The two workarounds I have found are to either load the source file into an editor that recognized "\n", "\r", & "\r\n" as line terminators (ex. PFE) then resave the file, or to write a filter to handle the translation. Roy Wright, Cisco Systems royw@cisco.com 1-512-378-1234 ------------------------------ Date: Mon, 17 May 1999 16:36:17 -0700 From: Andrew J Klossner Subject: Re: Wrong e-mail address (Wampler, RISKS-20.39) All the risks that Bruce Wampler mentions for misaddressed e-mail have been present for centuries with misaddressed paper mail. Mangle one digit of a street address and your envelope can quietly go to the wrong place. It's then up to the good graces of the inadvertent recipient to reroute it and to respect its confidentiality. The only difference I note is that important but misaddressed paper mail has a noteworthy appearance to distinguish it from bulk commercial advertisements, and is therefore less likely than e-mail to be discarded unnoticed. Andrew Klossner (andrew@pogo.wv.tek.com) ------------------------------ Date: Mon, 17 May 1999 12:28:40 -0400 From: Forbes_Thayne@emc.com Subject: Re: Risks of 3-letter user IDs (Yurman, RISKS-20.39) It's worse than he thinks. First, I spoke with a friend who works at Hotmail and they currently have about 43 million subscribers. Surprisingly, about 1/3 log in every day. Assuming yahoo! and the rest are in the same ballpark, then Dan is off by an order of magnitude. Furthermore, people at these sites frequently get mail that was meant for the same username at another site. I.e. jsmith@hotmail gets mail meant for jsmith@yahoo.com. Their friends just can't remember what site they are at. (I have this problem with my kids, who all have free accounts SOMEwhere). Lastly, I would have thought that I could get an account with my name (thayne) but could not. I got forbes_thayne, but was surprised to learn that there is actually someone else on the net with the same combination of slightly unusual names. I guess the lesson is that when you are dealing with millions of monkeys, anything is possible. ------------------------------ Date: Mon, 17 May 1999 17:24:45 +1000 From: Daniel Rutter Subject: Dimwitted naughty-word filtering lives... I'm a subscriber to the Healthfraud discussion list (e-mail healthfraud-help@ssr.com for info), and every now and then get a warning e-mail from the Healthfraud ezmlm program telling me that messages to me have been bouncing, with the usual note that if the warning bounces too I'll be unsubscribed. Often, the bounces are because my mailbox has been filled. My ISP here in Australia, Dialix (http://www.dialix.com.au/), allows its users only a 1Mb mailbox, which is OK with me because I check mail often and can access the local Dialix mail server much faster than the other couple of servers available to me. If a friend decides to send me a monster AVI file, though, a few messages will bounce before I clear the blockage. Other bounces, though, are because of "suspicious keywords in FROM:", according to the Dialix mail server error message; some source e-mail addresses don't pass muster with the server. For this reason, I will of course never see the error messages myself unless something, like ezmlm or a human with a different e-mail address from the one that bounces, brings them to my attention. I have just discovered that these "suspicious keywords" are defined to include dirty words, even if these words are coincidentally included in an innocuous non-spam e-mail address, on the assumption that any e-mail address with a dirty word in it must be from a spammer spruiking a sex site, or some such. So, for example, messages to the Healthfraud list from a retired nurse with the e-mail address nursex@... never made it to me. I presume e-mail from people called Frederick Uckham or Shirley Travis might not make it, either, if their e-mail addresses were composited from their names in an unfortunate way. I have no way of knowing how much valid e-mail has been bounced by this this over-inclusive, misguided "anti-spam" system. Dialix provides absolutely no notification for its users about the existence of the system. I didn't even know it existed until a Dialix support person e-mailed me with the news that he'd removed "sex" from the exclusion list for the mail server at _my_ Dialix point of presence, and was still trying to FIND the master exclusion list! The RISK - don't assume that your ISP isn't doing stupid, STUPID things just because they don't say they are, and don't get cocky about the reliability of e-mail. Dimwitted system administrators can silently zot your e-mail better than any random Internet problem. Daniel Rutter - DNRC Gadget Wrangler http://www.fromorbit.com/drutter/ http://www.dansdata.com/ - in-depth hardware reviews and more! ------------------------------ Date: Mon, 17 May 1999 10:57:05 -0800 From: Rob Slade Subject: REVIEW: "Removing the Spam", Geoff Mulligan BKRMSPAM.RVW 990328 "Removing the Spam", Geoff Mulligan, 1999, 0-201-37957-0, U$19.95/C$29.95 %A Geoff Mulligan %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1999 %G 0-201-37957-0 %I Addison-Wesley Publishing Co. %O U$19.95/C$29.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %P 190 p. %T "Removing the Spam: Email Processing and Filtering" This book is intended for the system manager, rather than the end user. More specifically, it is aimed at the mail administrator for an ISP (Internet Service Provider) or corporate network. Slightly unfortunate is the fact that it becomes more particular still, being of greatest use to those running UNIX, sendmail, ProcMail, and either Majordomo or SmartList. Regardless of system expression, anti-spam configuration is, as Mulligan points out, important for two reasons. The lesser of the two concerns is the most obvious: that of restricting the amount of spam reaching your own users. The more vital is that by failing to restrict the possible abuse of your system by spammers, and particularly by permitting unrestricted relays, you face the increasing possibility of becoming blacklisted, and therefore hampering the legitimate use of the net by your clients. Chapter one is an excellent overview of electronic mail. It is concise, complete, and accurate. Newcomers to the field will find not only a conceptual foundation for all the aspects of Internet e-mail, but also pointers to other references. Professionals will find fast access to a number of details that need to be addressed on a fairly frequent basis. The main theme, of course, is how spam uses the functions of e-mail systems, and how it can be impeded, with as little impact as possible on normal communications. A good framework is presented in this chapter, with a number of references to spam- fighting resources. If I were to make one suggestion, it would be to increase the number of examples of forged e-mail headers, and how to dissect them. Chapter two describes sendmail, and goes into sufficient detail for interested people to obtain it and start using it. At that point, the text concentrates on barriers to spam, such as restriction of relaying and the access database. Administrators using sendmail will find this a quick guide to basic functions. ProcMail has a variety of functions, and most of chapter three looks at the number of uses it can have. The spam filtering section is relatively brief, but provides some recipes, and directions to other ProcMail based filters. Again, sysadmins can use this as a quick start for basic mail processing. Chapter four doesn't have a lot to say about spam, but it does review the proper setup of mailing lists, which can have a significant impact in reducing unwanted mail. This book should be required reading for all mail administrators. The usefulness is not restricted to spam, since admins will be able to find brief discussions of a variety of common mail problems. As Mulligan notes, the fewer improperly configured mail servers there are out there, the more constricted spam sites will become, until at last they can be eliminated altogether. While the details of managing other mail server programs may not match those given in the book, the functions should be available, and should be turned on. If the functions aren't available, perhaps it's time you got some new software. copyright Robert M. Slade, 1999 BKRMSPAM.RVW 990328 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 23 Sep 1998 (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. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, 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 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.40 ************************