Movatterモバイル変換


[0]ホーム

URL:


The RISKS Digest
Volume 20 Issue 40

Tuesday, 18th May 1999

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy,Peter G. Neumann, moderator

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 thewebsite maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

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
Info on RISKS (comp.risks)

Nuclear plant Y2K: High risk-readiness or high-risk readiness?

"Perry, Mike" <mperry@europe.dg.com>Mon, 17 May 1999 16:05:42 +0100
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 limiterserves any valid safety purpose, nor that running it outside the limitsprescribed by the manufacturers carries any RISKs....Mike Perry  Data General Ltd

Biometric risks

Dan Wallach <dwallach@cs.rice.edu>Fri, 14 May 1999 14:51:51 -0500
Bank United of Texas has said they're about to introduce retina scanners toauthenticate their customers to an ATM [1].  No more PINs.  No more plasticcards.  The article says they'll be using technology from Diebold, althoughno such technology is described on Diebold's Web page [2].RISKS readers should be well aware that there are three different kinds ofauthentication (something you know, something you have, or something youare), and relying strictly on any one is a recipe for disaster.  Aparticular concern with purely biometric authentication systems is thatthere's no way to revoke your retina and get a new one.  If somebody managesto make a copy, you're out of luck.Says the article: "In response to questions about privacy concerns, BankUnited said the iris pictures will not be distributed to anyone outside thebank."Naturally, this is deeply unassuring.  Even assuming we don't have bad guysgoing around cutting out people's eyes, and even assuming the ATM vendor issmart enough to verify the eye has a pulse (i.e., it's still connected toits owner's head), there isn't a whole lot preventing some other vendor fromphotographing your iris and using your biometric against you.Also from the article: ``It has a very high cool factor,'' Coben said. ``Wethink of it as James Bond meets stocks and bonds.''Hopefully, Bank United will have a golden eye for detail, and will never saynever 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]

Singaporean ISP scans users' PCs

Andrew Brydon <andrew@isbjorn.demon.co.uk>Sat, 15 May 1999 07:09:50 +0100
Daily Telegraph (UK) Thursday 13th May 1999 - Connected (IT pullout) p.2Singaporean Internet provider SingNet has apologised to its subscribersafter scanning their PCs without their knowledge. SingNet asked theSingaporean Home Affairs Ministry to help check the computers of its 200,000subscribers in the wake of the damage caused by the CIH virus.Unfortunately for SingNet an anti-hacking program being used by a customerpicked up scanning, which was reported to the police. The scan was tracedback to the government. The company says it did not look at any confidentialfiles but did find that 900 subscribers have virus- infected computers.Andrew Brydon, Systems & Software Safety Analyst

ATMs gobble up cash cards

John Colville <colville@socs.uts.edu.au>Mon, 17 May 1999 09:16:37 +1000
From AAP via Sydney Morning Herald, Monday may 17, 1999, p4with insertions by JC in [ ].Many St George Bank [Australia's fifth largest bank] customers were leftshort at the weekend when automatic teller machines gobbled up their cashcards as the bank installed a new computer system.The bank refused to say how many customers lost their cards.  [The bankprobably do not know how many cards were 'gobbled' yet because they wereclosed from their normal Saturday morning trading in preparation for thechangeover.]A spokesman said the problem occurred because of the expiry dates on certaincards.  Canberra resident, Mr Steve Pye, who lost his card on Saturday, saidthere would be no replacements until Wednesday for "people like me with nomoney in my pocket . . .  "I'm as mad as hell about it."John Colville, University of Technology, SydneyBroadway, NSW, Australia, 2007  colville@socs.uts.edu.au  +61-2-9514-1854

Web browsers, URL collisions, and all that...

Zygo Blaxell <uryse0d5@umail.furryterror.org>16 May 1999 04:05:45 -0400
This happened to me the other month: an interesting interaction between twoconvenience features in web browsers and operating systems.Where I work there is an internal server (let's call it 'qqq') thatmaintains some data used by the group I work in.  The machine generates testdata and serves dozens of report pages all hyperlinked together andaccessible via a web client.  Because it's on a corporate intranet, alldesktop machines that can access the server happen to be configured suchthat they are able to use the short version of the server's name, ratherthan 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 lookupswill find the right host.  This is a convenient, time-saving feature.On the public Internet, by contrast, there is a widespread convention for aweb server owned by "The Example Corporation" to be named "www.example.com".No doubt this convention was influenced by Netscape's decision toautomatically expand bare hostnames typed into the "Location" field byprepending "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 wouldtype 'qqq' into the Location: field of Netscape, and we would get "serverdoes 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 mostlyharmless.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 thatwhen 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 usingthe new host name.To make matters worse, Netscape can sometimes do this even after it hasalready done the DNS lookup on the host name.  If this happens at just thewrong time, it means that the remote system with the similar name gets allthe information we would have sent to our own server: names and passwordsused to authenticate with the local server, any cookies set by programs onthe 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 includedeverything from credit card numbers and purchase details to complete credithistories from applications for financing.Interestingly enough, this problem never happened at one of my formeremployers, which has a different policy for corporate host names.  Theyinsist on naming all hosts according to a company-wide encoding system thatincludes machine type, function, location, partial encoding of the IPaddress, and a check digit, which results in tens of thousands of machineswith host names like "n3rndghh" or "amhjrxml".  To date I know of nobody whohas ever registered the domain name "www.n3rndghh.com", nor any other .comdomain name that is valid in the scheme used by my former employer, so therehave probably been no such collisions to date (although of course it'salways possible to cultivate one).Zygo Blaxell, Linux Engineer, Corel Corporation.  zygob@corel.ca (work) orzblaxell@furryterror.org (play).

False Viruses

"GILG,THOMAS J (HP-Corvallis,ex1)" <Thomas_Gilg@ex.cv.hp.com>Mon, 17 May 1999 15:08:59 -0700
When the Melissa virus hit, everyone in our R&D software lab updated theirvirus checkers and went into inoculation and quarantine mode.  Several weekslater, I tried to run one of my old utility applications written inMicrosoft Visual Basic (VB) and compiled into a .exe, and it was suddenlyflagged as a "Backdoor.Trojan" virus.  While the UNIX & Java in me saw greathumor 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 intoa Visual C++ COM object resulted in some VB .exe code that looked like avirus. Changing the type, order and number of parameters in a function calland/or changing the location from which the function call was made wouldinfluence whether or not the resulting .exe looked like a virus.  For thoseinterested, 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", 2I reported the problem to the virus checker company, and they confirmed some"false detection" cases. Fortunately for both of us, their latest virusdefinition update contained a fix for this problem.  Unfortunately for someother folks in our lab, they ran into the same false virus alert with theirVB 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 alsooccurred to me that the publication of false alert notices has its own setof risks.Thomas Gilg, R&D Software Engineer, Hewlett-Packard  thomas_gilg@hp.com

HotMail is no Early Bird: happy99.exe

Malcolm Pack <mpack@email.com>Sat, 15 May 1999 08:57:59 +0100
A colleague at work was browsing his personal e-mail on HotMail, and askedme innocently if I knew what "HAPPY99.EXE" was, since someone he knows hadsent it to him as an attachment. I explained that it was a "worm", and heshould: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 correctlyidentify the worm as W32/Ska.exe.I have requested an explanation from HotMail, and will forward what Ireceive.In the meantime, trust no one[2].[0] Interestingly, an Infind <http://www.infind.com> 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 <mpack@email.com>

Virus cleaner corrupts e-mail database

Diomidis Spinellis <dspin@aegean.gr>Tue, 18 May 1999 11:39:59 +0200
I was told the following story by an associate who is managing a largedistributed IT installation.  The administrators at one site installed ananti-virus product on a machine running the Microsoft Exchange e-mailserver.  Exchange keeps all incoming mailboxes in a monolithic databaseof a proprietary format.  The administrators enabled a parameter of thevirus scan program to automatically clean the virus-infected files.  Thevirus scanner detected an instance of the CAP macro virus in a mailattachment WITHIN the Exchange database and proceeded to "clean" the file byperforming an in-place modification on it.  As a result the database wascorrupted, users could not access their mail, and subsequent attempts torepair the database using the facilities provided by Exchange failed.Eventually the database was recovered from a backup resulting in lost e-mailmessages.  There are many lessons that can be drawn from this story; I wouldlike to emphasise the risks of proprietary, opaque, or gratuitouslycomplicated file formats such as those used by Microsoft Word documents, andthe Exchange database.  Architecting and implementing an efficient,extensible, and functional file format and interface can be difficult andexpensive.  However, the cost is most cases justified the resultingrobustness, openness, usability, and extensibility of the system.Diomidis Spinellis, University of the Aegean

MIME-Messages: quoted-printable chars in URLs

Christoph Conrad <Christoph.Conrad@post.rwth-aachen.de>17 May 1999 07:19:56 +0200
Recently I made a request for an X509-certificate. The certificationauthority (CA) mailed me an URL for fetching my certificate, but it didn'twork. It looked like ([...] parts are omitted by me):http://[...]CertIdentifierW746So I wrote back to them and they answered that the last five digits arefive seven seven four six, before the equal sign. I realized that this isa problem with MIME quoted-printable handling.The real URL was:http://[...]CertIdentifier=57746"=57" is also a quoted printable char and means "character with value0x57", this is a 'W'!christoph.conrad@post.rwth-aachen.de

New-fangled petrol pumps

Ian Chard <ian@tanagra.demon.co.uk>Thu, 13 May 1999 21:50:38 +0100 (BST)
I filled my car up with petrol today with one of these new-fangled petrolpumps that lets you stick your credit/debit card in, fill up you car andthen drive away without having to queue up in the shop.  I didn't reallytrust the pump (and I thought the poorly trained staff might think that Iwas just driving away without paying), so I asked it for a receipt.  Ireached under the pump (where the printer is), grabbed the receipt, anddrove away.When I got home, I fished the receipt out of my pocket, and it struck methat 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 thecard type was "MASTERCARD", which I don't have.  "Hmm," I thought, "maybe itjust represents Switch (my card type) as Mastercard.  Then I noticed thatthe first digit of the (full) card number on the receipt was a 5, whereasmine was a 6.  Then the penny dropped.The printer took rather longer than I thought to print the receipt.  What Igot was someone else's receipt, with their full credit card number andexpiry date.  To my horror, I also realised that the next customer will getmy card number and expiry date.  Alas, it was now 30 minutes later, and mydetails are almost certainly in someone else's pocket.The RISK here is not only that old adage about not printing the full cardnumber when the last five digits will do.  I wouldn't have had a problem ifthe thing had said "PRINTING PLEASE WAIT".  What it did say was "PLEASE TAKERECEIPT FROM BELOW PUMP".  I looked, saw a piece of paper, and took it.Ian Chard, Sheriffmuir <ian@tanagra.demon.co.uk>  +44 976 249081http://www.tanagra.demon.co.uk

Re: C compilers vs editors: WYSI NOT ALWAYS WYG (Graifer,RISKS-20.39)

"Roy O. Wright" <royw@cisco.com>Mon, 17 May 1999 17:02:06 -0500
In MS Visual J++, Microsoft will sometimes use a single carriage return as aline terminator.  As pointed out by Daniel Graifer, this can introduce bugswhen moving the source code to a different compiler - EVEN ON THE SAMEPLATFORM (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 toolsor very sloppy design.The two workarounds I have found are to either load the source file into aneditor 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

Re: Wrong e-mail address (Wampler,RISKS-20.39)

Andrew J Klossner <andrew@pogo.WV.TEK.COM>Mon, 17 May 1999 16:36:17 -0700
All the risks that Bruce Wampler mentions for misaddressed e-mail have beenpresent for centuries with misaddressed paper mail.  Mangle one digit of astreet address and your envelope can quietly go to the wrong place.  It'sthen up to the good graces of the inadvertent recipient to reroute it and torespect its confidentiality.The only difference I note is that important but misaddressed paper mail hasa noteworthy appearance to distinguish it from bulk commercialadvertisements, and is therefore less likely than e-mail to be discardedunnoticed.Andrew Klossner (andrew@pogo.wv.tek.com)

Re: Risks of 3-letter user IDs (Yurman,RISKS-20.39)

<Forbes_Thayne@emc.com>Mon, 17 May 1999 12:28:40 -0400
It's worse than he thinks.  First, I spoke with a friend who works atHotmail and they currently have about 43 million subscribers.  Surprisingly,about 1/3 log in every day.  Assuming yahoo! and the rest are in the sameballpark, then Dan is off by an order of magnitude.  Furthermore, people atthese sites frequently get mail that was meant for the same username atanother 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 thisproblem with my kids, who all have free accounts SOMEwhere).  Lastly, Iwould have thought that I could get an account with my name (thayne) butcould not.  I got forbes_thayne, but was surprised to learn that there isactually someone else on the net with the same combination of slightlyunusual names.  I guess the lesson is that when you are dealing withmillions of monkeys, anything is possible.

Dimwitted naughty-word filtering lives...

Daniel Rutter <drutter@curie.dialix.com.au>Mon, 17 May 1999 17:24:45 +1000
I'm a subscriber to the Healthfraud discussion list (e-mailhealthfraud-help@ssr.com for info), and every now and then get a warninge-mail from the Healthfraud ezmlm program telling me that messages to mehave been bouncing, with the usual note that if the warning bounces too I'llbe unsubscribed.Often, the bounces are because my mailbox has been filled. My ISP here inAustralia, Dialix (http://www.dialix.com.au/), allows its users only a 1Mbmailbox, which is OK with me because I check mail often and can access thelocal Dialix mail server much faster than the other couple of serversavailable 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-mailaddresses don't pass muster with the server. For this reason, I will ofcourse never see the error messages myself unless something, like ezmlm or ahuman with a different e-mail address from the one that bounces, brings themto my attention. I have just discovered that these "suspicious keywords" aredefined to include dirty words, even if these words are coincidentallyincluded in an innocuous non-spam e-mail address, on the assumption that anye-mail address with a dirty word in it must be from a spammer spruiking asex site, or some such.So, for example, messages to the Healthfraud list from a retired nurse withthe e-mail address nursex@... never made it to me. I presume e-mail frompeople called Frederick Uckham or Shirley Travis might not make it, either,if their e-mail addresses were composited from their names in an unfortunateway. I have no way of knowing how much valid e-mail has been bounced by thisthis over-inclusive, misguided "anti-spam" system.Dialix provides absolutely no notification for its users about the existenceof the system. I didn't even know it existed until a Dialix support persone-mailed me with the news that he'd removed "sex" from the exclusion listfor the mail server at _my_ Dialix point of presence, and was still tryingto FIND the master exclusion list!The RISK - don't assume that your ISP isn't doing stupid, STUPID things justbecause they don't say they are, and don't get cocky about the reliabilityof e-mail. Dimwitted system administrators can silently zot your e-mailbetter than any random Internet problem.Daniel Rutter - DNRC Gadget Wranglerhttp://www.fromorbit.com/drutter/http://www.dansdata.com/ - in-depth hardware reviews and more!

REVIEW: "Removing the Spam", Geoff Mulligan

Rob Slade <rslade@sprint.ca>Mon, 17 May 1999 10:57:05 -0800
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 isthe fact that it becomes more particular still, being of greatest use tothose running UNIX, sendmail, ProcMail, and either Majordomo or SmartList.Regardless of system expression, anti-spam configuration is, as Mulliganpoints out, important for two reasons.  The lesser of the two concerns isthe most obvious: that of restricting the amount of spam reaching your ownusers.  The more vital is that by failing to restrict the possible abuse ofyour system by spammers, and particularly by permitting unrestricted relays,you face the increasing possibility of becoming blacklisted, and thereforehampering 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 aconceptual foundation for all the aspects of Internet e-mail, but alsopointers to other references.  Professionals will find fast access to anumber of details that need to be addressed on a fairly frequent basis.  Themain theme, of course, is how spam uses the functions of e-mail systems, andhow it can be impeded, with as little impact as possible on normalcommunications.  A good framework is presented in this chapter, with anumber of references to spam- fighting resources.  If I were to make onesuggestion, it would be to increase the number of examples of forged e-mailheaders, and how to dissect them.Chapter two describes sendmail, and goes into sufficient detail forinterested people to obtain it and start using it.  At that point, the textconcentrates on barriers to spam, such as restriction of relaying and theaccess database.  Administrators using sendmail will find this a quick guideto basic functions.ProcMail has a variety of functions, and most of chapter three looks at thenumber 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 theproper setup of mailing lists, which can have a significant impact inreducing unwanted mail.This book should be required reading for all mail administrators.  Theusefulness is not restricted to spam, since admins will be able to findbrief discussions of a variety of common mail problems.  As Mulligan notes,the fewer improperly configured mail servers there are out there, the moreconstricted spam sites will become, until at last they can be eliminatedaltogether.  While the details of managing other mail server programs maynot match those given in the book, the functions should be available, andshould be turned on.  If the functions aren't available, perhaps it's timeyou got some new software.copyright Robert M. Slade, 1999   BKRMSPAM.RVW   990328rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.comhttp://victoria.tc.ca/techrev    orhttp://sun.soci.niu.edu/~rslade

Please report problems with the web pages tothe maintainer

x
Top

[8]ページ先頭

©2009-2025 Movatter.jp