Text File

precedence: bulk Subject: Risks Digest 20.34

RISKS-LIST: Risks-Forum Digest Weds 28 April 1999 Volume 20 : Issue 34

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 <URL:http://catless.ncl.ac.uk/Risks/20.34.html> and at ftp.sri.com/risks/ .

Contents: Virus infects computers worldwide (Edupage) A genuine sighting of a virus -- for once (Nick Brown) Sex aid give holiday flight a shaky start (Frank Markus) A Supreme Indecency (Monty Solomon) Bar says e-mail OK for transmissions (Monty Solomon) You'd think they'd know better... (T Bruce Tober) A man charged with counterfeiting bank ATM cards (Chiaki Ishikawa) What's DejaNews up to? (Richard M. Smith) Dodgy automatic address book resolution (Samuel Liddicott) Re: GUIDs and Melissa (Russ Cooper) REVIEW: "Great Misadventures", Peggy Saari (Rob Slade) Open Source Software at 1999 USENIX Annual Conference (Jennifer Radtke) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Wed, 28 Apr 1999 12:41:33 -0600 From: Edupage Editors <edupage@franklin.oit.unc.edu> Subject: Virus infects computers worldwide

The Chernobyl virus yesterday attacked more than 600,000 home, office, and government computers around the world, causing an estimated hundreds of millions of dollars in damage. The virus, which struck on the 13th anniversary of the Chernobyl nuclear explosion and is named for the disaster, is believed to have its roots in Taiwan. Windows 95 and Windows 98 files are attacked by the virus, which tries to erase the hard drive and prevent the computer from being booted. However, no large-scale system failures have been reported. In the United States, reports of 2,328 infected computers at 228 locations were made to the Computer Emergency Response Team at Carnegie Mellon University. The most severely impacted country appears to have been South Korea, where as many as 300,000 computers were affected by the virus. The virus may have damaged as many as 15 percent of all computers in South Korea, and could cost the country $250 million, according to a South Korean news agency's quotes of industry experts. In Turkey, computers were affected at an airport, a military academy, the state-run radio and television station, and several banks. Electronics engineer Mustafa Ucoklar says Turkey was caught unprepared and the country had not taken notice of warning signs. (*The Washington Post* 28 Apr 1999; Edupage, 28 Apr 1999)

------------------------------

Date: Tue, 27 Apr 1999 09:20:40 +0200 From: BROWN Nick <Nick.BROWN@coe.int> Subject: A genuine sighting of a virus -- for once

I dropped into my friendly neighbourhood computer dealer last night to find not one but two guys standing there with their PCs. Both with the same symptom - CIH/Chernobyl had trashed their BIOS. For once, a virus really struck ! That's two in one day in Molsheim, France (pop 8,000).

One of the PCs was from the shop itself, and the owner was obviously a hacker. He took it in reasonable spirits, although round here he'll probably be $75 down for a new BIOS chip. The other was from a local hypermarket, seven months old. I suggested to the owner that he take it back to the shop under warranty. This kind of store can't do proper after-sales for software problems, of course, but they might be persuadable that a completely black screen at startup could be a broken motherboard.

In fact, it would be interesting to see what various countries' consumer laws make of "my BIOS was trashed by a malicious program, and my PC no longer boots". PC stores (and corporate support desks) already have quite enough people expecting them to fix problems caused by screwing around with OS files, but how responsible can someone be for the care of their BIOS chip?

The RISK ? Well, apart from the obvious virus-related ones, there's the problem of getting repairs under warranty in those grey areas between "the system broke" and "you broke the system".

Nick Brown, Strasbourg, France

------------------------------

Date: Sun, 25 Apr 1999 06:26:07 -0400 From: "Frank Markus" <fmarkus@pipeline.com> Subject: Sex aid give holiday flight a shaky start

A pilot made an emergency landing when a suspect device was detected on a jet packed with British holiday makers -- but the threat turned out to be a sex-aid vibrator.

The A-300 Monarch Airbus was two hours into a flight from Goa when the crew became suspicious about a piece of hand luggage. The pilot, Captain Dave Johnson, radioed a bomb alert and was ordered to divert to Bombay.

The plane, carrying British-based passengers and crew, was taken to an isolated handling bay where 369 people were evacuated. Bomb disposal experts boarded the plane and examined the suspect baggage and identified the device as a battery-powered sex vibrator. A Monarch Air spokeswoman applauded Capt Johnson's actions. "We are looking into the incident to find out how it got on board," she said. The passengers later continued to Gatwick.

I initially found this story in rec.travel.airlines on Usenet. I followed the links in that message to the actual article (above, Tuesday April 20, 11:01 AM). The next message posted was from an airline ramp agent:

"Actually, this kind of thing happens way too often. I used to work for a major airline as a ramp agent, and I'd put the number at 2-3 times per year, per airline. What happens is a bag (usually checked though) gets jostled, and vibrator switches on, bag starts buzzing or humming, employees alert security, and then the real fun begins.

"Our SOP used to be offload pax, have them claim baggage on ramp, then swoop in on suspicious bag. have pax reveal source of buzz, worst embarrassment of life ensues, in front of planeload of angry, delayed strangers. It was ALWAYS the best part about working the ramp. And this should serve as a cautionary note, pack the batteries separate if traveling with a vibrator."

I love this story. It has everything that is required for an urban legend but it is true. The original story is still available at: http://www.yahoo.co.uk/headlines/19990420/london/newsstory133839.html

[I thought maybe the "vibrator" was related to the vi editor, since "vi" is s*x in Roman numerals. PGN]

------------------------------

Date: Wed, 28 Apr 1999 10:57:32 -0400 From: Monty Solomon <monty@roscom.com> Subject: A Supreme Indecency

Congress tried to make it a felony to say anything "indecent" online "with intent to annoy" another person. The Supreme Court has just decided the appeal in the case testing the law.

It had to be the shortest Supreme Court decision on the merits of a First Amendment issue ever: "The judgment is affirmed." ApolloMedia Corp. v. Reno, No. 98-933 (April 19, 1999).

http://www.lawnewsnetwork.com/opencourt/stories/A939-1999Apr27.html

------------------------------

Date: Wed, 28 Apr 1999 10:50:33 -0400 From: Monty Solomon <monty@roscom.com> Subject: Bar says e-mail OK for transmissions

The American Bar Association has given its seal of approval to the use of e-mail to transmit client documents.

Under most circumstances, a lawyer does not violate a client's confidentiality by transmitting documents via unencrypted electronic mail, the ABA Standing Committee on Ethics and Professional Responsibility concluded in an ethics opinion announced last week.

http://www.lawnewsnet.com/stories/A953-1999Apr27.html

------------------------------

Date: Sun, 25 Apr 1999 13:13:34 +0100 From: T Bruce Tober <octobersdad@reporters.net> Subject: You'd think they'd know better...

...or maybe not. I mean, it is Microcrap we're talking about here, viz this article from Woody's (Woody's Office Watch), and if there's anyone more pro-Microsoft it's only Bill G himself,: (Read the complete story http://www.wopr.com/ )

TRUST NO ONE [...] Microsoft has in the past released virus infected documents on their web site and by other means. WOW has had to publish warnings several times. Sadly it's happened again. Anyone visiting http://www.microsoft.com/uk/business_technology/dns/ecommerce/financial/case.htm to find out more about MS Exchange and E-commerce got more than they bargained for when they downloaded any of the case study documents. All were infected with W97M/Marker.C virus! Apparently no-one at Microsoft checked the documents before making them publicly available [...]

Bruce Tober, <octobersdad@reporters.net>, <http://www.crecon.demon.co.uk> Birmingham, UK, EU +44-121-242-3832 soon at <http://www.star-dot-star.co.uk>

------------------------------

Date: Thu, 29 Apr 1999 04:43:00 +0900 (JST) From: Chiaki Ishikawa <Chiaki.Ishikawa@personal-media.co.jp> Subject: A man charged with counterfeiting bank ATM cards

Lately about a dozen people whose account reside in two Japanese banks found their money withdrawn by unknown third party. Police began investigating and found, from the video tape recording of the ATM machines where withdrawals took place, a man seemed to have used fake bank ATM cards and withdrew the money from ATM machines in Tokyo area.

Last week, the police arrested a man and charged him for the theft.

But how did this man find about the existence of the bank account and that the man found the password or PIN? It turns out that the man worked for a software company that subcontracted the reservation system maintenance for a city-operated resort facility from an NTT group company. All the people whose money was stolen made a reservation to the city facility at least once.

The city resort facility takes reservation from its citizens with advance partial payment. The hitch is that when the applicant cancels the reservation, the advance payment is returned to the applicant's bank account. For this purpose, the city office records the bank account information as well as other personal information such as telephone number, address, etc. in the database. All these reservation and cancellation work seems to be done via computer terminal.

The culprit who works at the company that manages the host computer for the reservation system obviously had access to the database of the reservation including the bank account (no encryption that keeps the maintenance operator to look inside?). So he could concoct a new ATM card by recording the information onto a magnetic-strip card using a magnetic card writer.

Now the second big question is how he figured out the PIN. (The card itself no longer carries PIN on itself.) Well, it seemed easy to him. Since he had access to the personal information such as telephone number, address, etc., he seemed to make educated guesses and obviously he succeeded. Sigh...

In the same article, some banks were quoted as thinking of making it possible for customers to change the PIN regularly. (I am not sure if this works well. If someone picks up bad password, will the person pick up good password next time? There may be human risks here, but am not sure.) For that matter, PIN for bank ATM cards here in Japan are only 4 digits! Shoulder-surfing certainly is possible.

Also, I just learned today that the culprit stole other people's bank cards in trains and so forth so that he could overlay the stolen bank account information on these cards to try his guessed PINS. Any physical checking done by the card reader itself seems to have been thwarted by the culprit's using otherwise genuine ATM cards. However, I don't know if any such checks are done by the card readers and cards used today in Japan. Maybe the culprit was very cautious. Police reportedly found fake credit card as well at the culprit's home, so in that case, nice-looking holograph, etc. was necessary for counterfeiting.

A few risk lessons from this incident:

Private database with sensitive information should be encrypted so that only the appropriate user can access its contents. The night-shift operator who do backup can carry a duplicate copy, etc.. Also, proper auditing of access to the database could deter such criminals. In this case, the city office could use a PC for terminal and use plain text information on that terminal alone and could store the encrypted information at the host computer managed by the company where the culprit works. (Sure, the search against the stored data record might be an issue here. But by storing the name in plain text and the rest in encrypted from, it should pose no big problem IMHO.)

ATM cards should be hard to fake in the first place. The bank officials were quoted in an Asahi shimbun article as saying that making counterfeiting like this impossible is very difficult technically.

I wonder if adding some information on the card, such as the md5 checksum of the concatenation of the closely kept secret master bank seed string + the ordinary infomration on the card such as the branch number, account number, holder's name, etc. could make the counterfeiting more difficult. Unless the counterfeiter knows the secret seed string it becomes impossible to fake the ATM. I guess such scheme would make the counterfeiting very difficult. But the bank people may not want to upgrade all the ATMs across the whole of Japan at once, or it may be that the ATM card used today may not hold all the md5 digits or even reasonable length of it capacity-wise. But probably they'll be forced to upgrade the security anyway by the social pressure in not too distant future. I was very surprised about this counterfeting being so easy myself.

Also, as has been said million times, don't use the obviously easy to guess PINs based on your telephone number, birth date, etc.. I am not sure if the database in question contains the birth date for the purpose of the reservation, but since the success rate seemed to have been high, it could. But if so, I will add another lesson here.

Don't collect unnecessary personal information. It will leak out or be abused in some way or the other. (Chiaki's law a la Murphy's law.)

Will computer IC card solve these counterfeting problems in the future?

Chiaki Ishikawa <ishikawa@personal-media.co.jp.NoSpam> Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051

------------------------------

Date: Sun, 25 Apr 1999 15:21:14 -0500 From: "Richard M. Smith" <rms@pharlap.com> Subject: What's DejaNews up to?

One of my favorite Web sites is DejaNews, the search engine for Usenet newsgroup messages. Yesterday I discovered a new "feature" of DejaNews which I don't understand.

It seems that when a newsgroup message containing URL's is displayed, the DejaNews server is silent changing the links to be routed through the DejaNews servers. This new feature allows DejaNews to track when a person clicks on a Web site link in a newsgroup message. You still get to the Web site, you just go through the DejaNews servers first. My understanding is that the new feature was added a couple of months ago.

Here is a quick example of what DejaNews is up to:

Original link: http://www.yahoo.com Tracking link: http://x12.dejanews.com/jump/http://www.yahoo.com

Apparently the DejaNews servers simply redirect your browser to the real URL after recording where you clicked. In the newsgroup message itself, the original link is shown, not the tracking link.

An easy way to defeat this tracking mechanism is to manually copy the link in the message text to the location or address window of your browser.

I ran a simple experiment and found that a Web site will still get the referring URL which is the URL of the newsgroup message. So one thing that DejaNews is not trying to do is block Web sites from knowing where a click came from.

Pretty obviously, DejaNews knows a lot about me already by my searching habits. Why do they now also need to know what Web sites I'm visiting? What is being done with this information?

Pretty odd if you ask me. What I can't figure out is what DejaNews is up to here. Does anyone have any ideas?

Richard M. Smith <smiths@tiac.net>

[Added note: It gets more interesting. DejaNews is also tracking e-mail addresses. When one clicks on an e-mail address in a newsgroup message, it first goes thru the DejaNews server before being redirect as a mailto: URL. DejaNews ends up know who and when someone is sending e-mail to. This is just plain weird.]

Here is more info from comp.security.misc:

donoli wrote:

> Exactly. Since they are chaining the URL, they get credit for bringing > users to the second site.

Yep, Web sites with high click-thru rates get called first by their friendly DejaNews ad rep!

Maybe the next step here for DejaNews is to somehow figure out how to charge Web sites for click thru's. Toll booths on the Internet? For example, maybe DejaNews only highlights links for Web sites that have DejaNews accounts. Each click-thru then costs a dime.

Why DejaNews went through all of the trouble to also track e-mail makes no sense at all. It's just plain rude. I've asked their privacy people and PR people what's going on. Hopefully they'll get back to me today.

BTW, According to Junkbusters.com, the hotbot search engine also does the same trick for Web sites. They are tracking click-thru's in search results. None of the other major search engines (AltaVista, Yahoo, Lycos, and InfoSeek) appear to be doing this.

Richard

------------------------------

Date: Mon, 26 Apr 1999 09:42:19 +0100 From: "Samuel Liddicott" <sam@campbellsci.co.uk> Subject: Dodgy automatic address book resolution

I work at Campbell Scientific.

It's not surprising that the managing directors has a last name "Campbell". (Lets pretend his first name is Bill)

I have IE5 and Outlook 98. In my address book is a local employee who shares the same first name as the overseas director. (Let's pretend it is Bill Prescott)

In an e-mail message I typed:

Bill Campbell

as the recipient, which my address book foolishly resolved to "Bill Prescott <bill@campbellsci.co.uk>

Doh! Just because there is a Bill in my address book with campbell in his e-mail address!

The risks? Expecting technology to abide by my definition of sensible. I thought I was typing a full name, the computer in its attempt to "do the right thing" was a little too eager. I was expecting the address book to fail to resolve, and that it would be picked up by the LDAP server.

The even worse risks? That "Bill Campbell" would work until "Bill Prescott", a distinctly different name appears in the address book.

Finally, in an effort to make software "do the right thing", it is worth evaluating when this might turn out to be a "very wrong" thing.

Sam Liddicott <sam@campbellsci.co.uk>

------------------------------

Date: Mon, 26 Apr 1999 23:08:06 -0400 From: Russ <Russ.Cooper@rc.on.ca> Subject: Re: GUIDs and Melissa (Baum, Risks 20.33)

>What's the point of a "Globally Unique ID" that isn't unique?

With all due respect, this isn't "Microsoft's one", its the OSF's definition of how to create GUIDs. Copy-and-modify puts your GUID on the modified document (over-writing the previous GUID), whereas cut-and-paste puts other content in a document with your GUID.

The GUID wasn't intended to uniquely identify the document, only the OS/Application installation it was created/last modified on.

For those that forget, NT 3.1 (from which all this GUID stuff stemmed for MS) was largely based on OSF/DCE. Arguments aside, they did implement the GUID creation process according to DCE spec.

Russ - NTBugtraq moderator

------------------------------

Date: Tue, 27 Apr 1999 08:42:19 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca> Subject: REVIEW: "Great Misadventures", Peggy Saari

BKGRTMSA.RVW 990318

"Great Misadventures", Peggy Saari, 1999, 0-7876-2798-4, U$99.00 %A Peggy Saari %C 27500 Drake Road, Farmington Hills, MI 48331-3535 %D 1999 %G 0-7876-2798-4 %G (0-7876-2799-2 0-7876-2800-X 0-7876-2801-8 0-7876-2802-6) %I The Gale Group/Gale Research Inc. %O U$99.00 248-699-4253 fax: 800-414-5043 %P ~800 p. %T "Great Misadventures: Bad Ideas That Led to Big Disasters"

Let us start with some cliches. Life is a hard teacher: she gives the test first, and the lesson afterwards. Good judgement comes from experience: experience comes from bad judgement. Those who do not learn from history (or History 205) are doomed to repeat it. We learn far more from failure than we do from success. And, finally, learn from the mistakes of others: you will never live long enough to make them all yourself.

If there was ever a book concept made for the RISKS-FORUM Digest library (aside from PGN's own) it is this: great boneheaded ideas from the past. In this junior edition, four volumes divide that topic into exploration, science and technology, military, and society.

Unfortunately, while the essays provide decent canned histories of the events, they make lousy lessons. All of the material is presented at the same level of very rough detail, rather than sketching in a background and then concentrating on a specific mistake. A number of decisions in any chapter may be identified as errors, but there is little commentary on why the action was wrong and contributed to the disaster in question. Why did this endeavour, intended to promote safety, ultimately spell catastrophe? If this person or institution was motivated by greed or ambition, at what point did the driving force behind development become a destructive power? While there is a lack of analysis overall, a particular failing is the lack of examination of options that might have changed the outcome for the better.

In the Reader's Guide starting each volume, the point is made that a calamity had some positive result, usually in terms of a reform or improvement. Relatively few of the stories, however, tell of any such correction. In both the Apollo 13 and Bre-X articles, in fact, the text has to admit that we do not know for sure what the causes of the problems were, and therefore no lesson can be drawn from them at all.

Of greatest interest to the largest number of readers of this series will be the article on the Year 2000 problem, otherwise known as the millennium bug or Y2K. Perhaps the kindest thing that can be said about this essay is that it will become academic in less than a year. The situation is blamed on an "error" (with no mention of the widely used standard), although the next paragraph states that it should not be called a "bug." Although Peter de Jager has worked tirelessly to bring the issue to the attention of the public, it is not true that nobody knew about it before his 1993 article. I have never seen any microwave oven that cared what the date was, and it is rather beyond the bounds of probability that an aircraft would shut down in flight because it felt miffed at being too long without a checkup. An entire section of the article confuses the predicament with the unrelated issue of maintaining archival records as generations of storage hardware and media pass by. The entire disaster is ultimately laid to the blame of "negligent" computer developers.

There are a number of sidebars, generally giving a biography of involved characters, and illustrations. The biographies sometimes seem at odds with either the essays of which they form a part, or oddly placed in proximity to more detailed accounts, and the figures, where placed in a piece, provide little explanatory support. The military section, for example, has numerous battle maps where the order of a campaign is extremely difficult to follow. (Yes, I know: war is messy.) Some of the diagrams, as originally produced, were probably supposed to be in colour, since the keys cannot, in the black and white version, distinguish between items of opposed significance. Much material is duplicated between pieces, but even that can be confusing at times. Many terms are explained in article after article, and the explanations are not always consistent. A musket will be defined as a "shoulder gun" in one essay, a "rifle" in another, and a "gun like a rifle" in a third. Not a great difference, but confusing. (The index does not assist in clarifying matters: there are lots of entries for people, but almost none for things.)

The cachet of disaster might make this an inviting set for promoting study of history in a rather "dates of the kings of England" manner. The events are isolated, the details are scanty, and the analysis almost doesn't exist. I doubt that students would learn much of either history or judgement from these books.

I should add, in view of the topical relation to the Risks Digest, that PGN's book is not only cheaper and *way* more accurate, but it's also more fun to read.

"Computer-Related Risks", Neumann, 1995, 0-201-55805-X, U$24.75

And it's possibly also time to mention Lauren Wiener's book again as well:

"Digital Woes", Wiener, 1993, 0-201-62609-8, U$22.95/C$29.95

copyright Robert M. Slade, 1999 BKGRTMSA.RVW 990318 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: Tue, 27 Apr 1999 16:11:59 GMT From: jennifer@usenix.ORG (Jennifer Radtke) Subject: Open Source Software at 1999 USENIX Annual Conference

[Item abridged for RISKS. PGN-ed]

*** Registration Savings until 3 May 1999 ***

Top developers, systems administrators, and other UNIX gurus get the why as well as the how-to at the reknown USENIX Annual Conference. The USENIX Conference takes place June 6-11, 1999, in Monterey, California. Programs for the tutorial and technical sessions, including the FREENIX track, and associated events are online. Please go to http://www.usenix.org/events/usenix99

The FREENIX track is devoted to high-level technical discussion of open-source software. USENIX has also provided a grant to the OpenBSD development project to support a new release. It will be distributed for free at the conference. USENIX is helping to ensure that the development process for open source software will continue to be characterized by intense yet healthy competition.

The refereed papers are on topics of especially high interest: management of resource systems, file systems, virtual memory systems, storage systems, security, web server performance and O/S performance. The Invited talks concentrate on the extremely practical; topics include: UNIX/Open System & Y2K, IP Multicast, e-mail Bombs, IPv6, IP Telephony.

John Ousterhout, creator of Tcl/Tk and leading figure in the open source world will deliver the conference keynote. His attention is on a fundamental shift in software development to integration applications -- created by coordinating and extending existing applications, protocols, frameworks, and devices.

24 tutorials are being offered over three days, with Eric Allman, Tom Christiansen, Peter Galvin, Evi Nemeth, and Marcus Ranum among the instructors. Courses range over systems administration, security, Linux, high availability, kernel internals, Perl, performance tuning, network programming and configuration, and more.

------------------------------

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 <risks-request@csl.sri.com> 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 <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>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.34 ************************