Text File

Subject: RISKS DIGEST 18.65

RISKS-LIST: Risks-Forum Digest Monday 9 December 1996 Volume 18 : Issue 65

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: Limits of automated newsgathering (Terry A. Ward) Crypto to protect ``bomb'' throwers (Peter Wayner) Another banking system hits the dust (John C. Bauer) Software hunts and kills Net viruses (Hans A. Rosbach) Don't touch this switch! (Rick Simpson) Blown Fuse Takes Out 911 System (Scott Lucero) Web content-substitution attack was a proxy-server fault (James Cameron) Risks of inappropriate encouragement (David M. Chess) Reuters computer tech brings down trading net (Steve L) Combatting cookies (Simson L. Garfinkel) MS-Access Runtime trashes WFW (Bob Price) Snowjob in selling computer books (Al Donaldson) "Computer errors cause several plane crashes" (Martin Minow) RISKS of frequent-flier long-distance promotions (Jonathan Clemens) Year 2000 and expiration dates (Robert Nicholson) Centralized computing (Darin Johnson) Re: Bell Atlantic 411 outage (Robert J. Perillo) Abridged info on RISKS (comp.risks)

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

Date: Wed, 4 Dec 1996 11:35:55 -0800 From: "Terry A. Ward" <terrywa@ix.netcom.com> Subject: Limits of automated newsgathering

I subscribe to the NewsPage Direct automated news service and a recent selection in HUMAN SEXUALITY highlighted the risk of confusing a rugby position with a sex-workers position:

>> RUGBY UNION-CANADIAN HOOKER OUT IN THE COLD - Canadian international hooker Karl Svoboda has been ousted from the Oxford team to face Cambridge University in the showpiece Varsity match at Twickenham next Tuesday. (Reuters)

[This is a scrum-ptious item! TNX. PGN]

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

Date: Mon, 9 Dec 1996 18:07:30 -0500 From: pcw@access.digex.net (Peter Wayner) Subject: Crypto to protect ``bomb'' throwers

*The Washington Post* (6 Dec 1996) reported that a radio and television broadcast of the annual Army/Navy football game would be distributed to many of the ships at sea in "encripted" form. The signal would be used to boost morale, although the encryption may ruin morale for the folks stationed at NSA/DIA listening posts. But perhaps the algorithm will be simple enough to be part of the challenge for them.

Of course, the automatic word scanners are sure to light up when words like "bomb" and "blitz" come over the air.

I wonder if they sign the broadcast with a digital signature to make sure an authentic version reaches the troops? Spoofed versions would be true info warfare. The enemy could ensure that both divisions would be demoralized by feeding a doctored version to the winning side. But then there is still the RISKS of the Air Force, who are in the big-bomb delivery department.

[Incidentally, for non-U.S.-football devotees, a "bomb" is a long pass, and a "blitz" is an extra-man defensive attack. I suppose "getting sacked" has multiple meanings in an Army-Navy game. PGN]

[Date typo fixed in archive copy. PGN]

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

Date: Mon, 2 Dec 1996 14:38:39 -0500 From: "John C. Bauer" <jcbauersyseng@igs.net> Subject: Another banking system hits the dust

On 30 Nov 1996, the Canadian Imperial Bank of Commerce Interac service was victimized by its attempted software upgrade, affecting about half of all would-be transactions across eastern Canada. [Source: Debit card failure angers customers, by Colin Freeze, Citizen Correspondent, The Ottawa Citizen, 2 December 1996, Ottawa, Ontario, Canada. PGN Stark Abstracting]

One business affected was Loblaw's, a grocery chain. Grocery stores do not accept credit cards. (My wife Ann says it may a provincial law.) I can just see someone with a cartful of groceries arriving at the checkout and being asked for cash they are not carrying.

As of 1 p.m. EST, 2 Dec 1996, the local branch of the bank had no statement to give to customers! Will this be touted as another example of computer people living outside the real world, where shopping is at a peak on Saturday afternoons, especially near Christmas?

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

Date: 02 Dec 1996 18:52:31 +0100 From: haro@sesam.dnv.no (Hans A. Rosbach) Subject: Software hunts and kills Net viruses

*The Sunday Times* (1 Dec 1996) wrote:

Software hunts and kills Net viruses

VIRUS-KILLING computer software that uses artificial intelligence to find and destroy new viruses is to be set loose on the Internet by IBM next week. The software, originally developed to play backgammon, will spread itself through the Net over the next year, learning how to kill new strains of virus as it goes. According to Gregory Sorkin, a researcher at IBM's Watson research laboratory, the system will be far more successful than humans at fighting computer viruses. "Once it learns the viruses already out there, the system will even be able to predict what new viruses will appear, and work out ways of stopping them before they even exist," says Sorkin. The system uses temporal difference, a method which relies on the computer looking for patterns within virus software, rather than individual lines of program code.

If I understand it correctly, this is software that will spread itself on the net, adapt itself, and destroy other things on the net.

How can something like this be tested? How can we be sure that the technology behind it will not be used to create the next generation of viruses? I find this scary.

Hans Amund Rosbach haro@sesam.dnv.no

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

Date: Thu, 05 Dec 96 18:13:54 -0500 From: "Rick Simpson" <simpson@watson.ibm.com> Subject: Don't touch this switch!

Today I attended a meeting in a large office building of a Major Computer Company. As I entered the conference room, the organizer of the meeting was trying to find a way to lower the projection screen from its storage place in the ceiling. There was no cord attached, so he was searching for a switch for the screen's motor.

On the wall next to the door was a push-button switch, brightly backlit in red, with a hand-written sign that read, "Don't touch this switch." (Also scribbled on the sign, in another hand, was "Don't touch" in Spanish.) The organizer seemed to think this might control the screen, so he pressed the button. Needless to say, the screen did not descend. The ventilation fans went off, though.

Several minutes later, a fellow poked his head in the door and asked, "Did someone touch that switch?" [Just like in a cartoon, isn't it?] "Yes," the organizer said, "we were trying to get the screen down."

"Don't touch the switch," said the man in the door, "It turns off the computer room next door."

The conference room was evidently once part of a raised-floor machine room, and the Emergency Power Off switch next to the door is still active.

The RISKS, I submit, are too obvious to list.

Rick Simpson IBM T. J. Watson Research Center Yorktown Heights, New York simpson@watson.ibm.com

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

Date: Tue, 03 Dec 96 05:21:48 EST From: lucero@optec.army.mil (lucero) Subject: Blown Fuse Takes Out 911 System

National Public Radio reports that a blown fuse took out a large portion of Iowa's 911 emergency phone system for three hours over the Thanksgiving weekend. U.S. West could not say how many 911 calls went unanswered. A spokesperson said that the troubles isolating the problem came from the complexity of the system. The RISKS are pretty evident.

Scott Lucero U.S. Army Software Metrics Program

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

Date: Tue, 3 Dec 1996 14:05:50 +1100 From: cameron@ripper.stl.dec.com (James Cameron) Subject: Web content-substitution attack was a proxy-server fault

I heard from a friend a detailed account of an apparent content substitution attack on his corporate web server that highlights a couple of risks. With his permission I have summarised the order of events:

- A few days ago, a sales person employed by the company reported a pornographic image had replaced the corporate logo on the main page.

- A correct logo was downloaded to the server within minutes, but before saving the existing image, thus erasing the evidence.

- Research showed a known defect in the operating system code that can be exploited to yield root access by remote users. Tests showed that the firewall and web server were vulnerable. Patches were obtained and installed to remove the vulnerability. Much effort.

- Conflicting data from logs appeared. The web server logs showed that the image had not been replaced. Firewall logs agreed. Web proxy server logs claimed otherwise.

- The pornographic image was found in the web proxy server cache, with a different URL, using a search by file size, and the logs confirmed that it had been viewed by users within the company.

- No evidence was found to prove that a break-in had occurred.

The staff deduced that the web proxy server had somehow mixed the pointers to the cached images, and had returned the incorrect image to the internal users. No reports were received from Internet users.

Risk: a web proxy server may change your view of the Internet, and may cause you to waste considerable time tracing a break-in that didn't happen.

Risk: allowing staff full access to the web increases the chances of a file mixup causing disturbance.

Also, there were no controls to ensure that CERT notifications were integrated into the firewall configuration. It took a suspected break-in before a search was made for vulnerabilities.

James Cameron (cameron@stl.dec.com) Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

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

Date: Wed, 4 Dec 96 10:39:13 EST From: "David M. Chess" <CHESS@watson.ibm.com> Subject: Risks of inappropriate encouragement

My daughter has a few multi-media-type CD-ROM games, and they are to various degrees cute / cuddly / talkative / friendly. The most talkative and friendly one has one very annoying and counterproductive habit. In the find-the-hidden-objects puzzle, the little voices on the speakers say happy / reassuring things every time you click the mouse on a place where there's no hidden object. "Try again!" "Nope, not there!" and so on. The encouraging phrases are as far as I can tell picked at random. Unfortunately, some of them have *semantics* beyond just "Try again".

The most annoying ones are "Ooh, not quite!" and "You're getting closer!". Because they're generated just at random, the voices can say "Ooh, not quite!" when the player is clicking as far as possible from the target, and can say "You're getting closer!" when in fact you're getting further away. My daughter learned to ignore the semantics of these messages very quickly (the plasticity of youth), but when looking over her shoulder I still find them annoying and misleading, and have to remind myself that they're meaningless.

The general tendency, the risk category, is a familiar and important one: computers that talk seem from the outside to know what they're saying, whereas the people who've made them talk may not really have thought it through at all, and the programs themselves can be arbitrarily stupid.

(Another similar program will say encouraging things like "Your eyes are as sharp as the eagle's" when the child finally gets all the rolling targets in the archery game, even if the player is far beyond the age-appropriate difficulty level, and has been struggling for many minutes to hit each one. Another, related, risk that reaches far beyond computers: overgenerous praise...)

David M. Chess High Integrity Computing Lab IBM Watson Research http://www.av.ibm.com/ http://www.research.ibm.com/massive

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

Date: Mon, 02 Dec 96 16:02:11 EST From: stevel@mcgraw-hill.com Subject: Reuters computer tech brings down trading net

Dealing rooms sabotaged by HK Reuters technician By Nicholas Denton in London and John Ridding in Hong Kong, 29 Nov 1996 Financial Times Limited

A disgruntled computer technician at Reuters in Hong Kong has caused the financial-information provider deep embarrassment by sabotaging the dealing-room systems of five of the company's investment bank clients. The attack crippled for up to 36 hours the computer systems bringing market prices and news to traders at NatWest Markets, Jardine Fleming, Standard Chartered, and two other banks. The banks, which resorted to alternative terminals such as Bloomberg, claimed the tampering had no significant impact on trading and said neither they nor their clients had experienced losses as a result.

The incident was reportedly the most serious breach of security disclosed in Reuters' corporate history, and is causing some rethinking of privileges. The maintenance engineer in question has been suspended. He apparently visited the client sites and initiated deferred commands to subsequently delete specific operating system files.

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

Date: Tue, 03 Dec 1996 08:25:13 -0500 From: "Simson L. Garfinkel" <simsong@vineyard.net> Subject: Combatting cookies

I've been thinking a lot about (web) cookies lately. One of the problem with the current situation is that you basically have two choices with the User Interface that both Netscape and Microsoft have created for your browsers:

1. You can simply accept all cookies. 2. You can have your browser warn you every time a cookie is sent your way and have the option of accepting it or not.

A cookie, for those not in he know, is a little tarball of data that gets sent to your browser. Cookies can be used to track users, by keying their browsers to a database. Or they can be used to preserve privacy, by storing private information on the user's browser, rather than on the web server.

Right now, a cookie gets sent to your browser whenever you get an HTTP response with the words "Set-Cookie:" in the header. After that, whenever you contact the web site, you send the cookie back.

It seems to me that an excellent way to deal with the cookie problem would be to have more user interface options:

* Simply do not accept cookies. * Specify who you will accept cookies from, and who not. * Accept cookies, but do not send them back. * Have a decent user interface to show which cookies you have and how often they are used. Let you delete them individually, rather than just all or nothing.

I've written more about cookies in an upcoming article for HotWired. It will appear at http://www.packet.com/garfinkel on Wednesday, 11 Nov 1996.

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

Date: Tue, 3 Dec 1996 13:25:24 -0500 From: Bob.Price@cwi.cablew.com Subject: MS-Access Runtime trashes WFW

Unless especial pains are taken, 16-bit MS-Acess runtime disks made on a Windows-95 machine with 16-bit Access will cause near-irreparable harm when installed on a WFW or Windows 3.1 machine. The reason is that some 32-bit system .DLLs are copied to the distribution diskettes (or network distribution set) along with the 16-bit files, and because the 32-bit files have the same names as the 16-bit files, the 16-bit platform no longer works properly. I'm told the official Microsoft paper on the subject says to format the hard drive and re-install everything. I was able to "recover" by upgrading to Windows-95; others have had success ferreting out the specific files and replacing them. Reinstalling WFW didn't fix anything.

Bob Price Cable & Wireless Inc. bobp0303@hotmail.com (703)760-3071

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

Date: Tue, 3 Dec 96 14:43:48 EST From: al@escom.com (Al Donaldson) Subject: Snowjob in selling computer books

January 1996 was a snowy month in Virginia. We were hammered by a storm on the 6th that dropped about two feet of snow, and closed everything (that wasn't already closed) for a couple of days, followed by another storm on the 12th that gave us another 8 or 10 inches.

So that Friday (12th), I spend most of the afternoon shoveling out my driveway. Then, remembering that I needed to buy a book to prepare for some computer work that weekend, I called my favorite technical bookstore to see if, by some chance, they might be open that night. (I didn't really expect them to be open, but it was worth a try...)

Sure enough, someone answered, so I asked how late they would be open. "Nine o'clock," was the answer. I confirmed the closing time, perhaps still not really believing they'd be open, then drove my 4WD truck about 15 miles on snowy roads to get there. But when I arrived around 8:00pm, the store was quite obviously closed.

That evening I sent off a letter of protest to the store management, who responded the following Monday that the *Virginia* store had been closed all day because of the heavy snow, and they'd forwarded the phones over to one of their California stores.

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

Date: Fri, 6 Dec 1996 17:15:03 -0800 From: Martin Minow <minow@apple.com> Subject: "Computer errors cause several plane crashes"

From an article in the Swedish newspaper, Aftonbladet, Dec 6, 1996 written by Claes Thunblad. http://www.aftonbladed.se/nyheter/dec/06/flyg.html

[[Note: while the Swedish translations I send to RISKS are usually from *Svenska Dagbladet*, one of the two "newspapers of record," this is from an evening tabloid, and should be understood as such. If you imagine my other translations as originating from *The New York Times* or *Daily Telegraph*, think of this as from the *New York Post* or *Evening Standard*. I've tried to be both accurate and true to the tone of the article. I've translated a bit more than 50% of the article, but omitted the sidebars listing recent air accidents. Swedish typographic conventions make it difficult to precisely mark quotations, and I apologize for any errors.]]

The advanced computer systems developed to improve flight safety have become a death trap. "Pilots can no longer keep track of everything," says Per-Olof Sk=F6ld, president of the Swedish pilot's organization. [[In bold-face on the web page.]]

"We've discussed this problem on several occasions. The critical point is when the computer system should be disconnected; when the pilot stops being a passive monitor of the system and becomes an active operator," says Sven-Eric Sigfridsoson of the national air accident commission.

The new advanced technology in airplanes was developed by technicians and engineers. They're the ones who test-fly the system before the plane is put into traffic.

"These things were designed by engineers and technicians are not always pilot-friendly. Today there are several automatic sequences that pilots can never keep track of," says Per-Olof Sk=F6ld. ... The pilot's nightmare scenario is that the technology will get even more advanced.

That's what the technicians want.

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

Date: Tue, 3 Dec 1996 11:56:58 -0800 (PST) From: Jonathan Clemens <jclemens@aa.net> Subject: RISKS of frequent-flier long-distance promotions

Several years ago, a local long distance carrier began a program offering one frequent flier mile for each minute of long distance calling. My sister signed up for the program, but later moved and disconnected that particular phone line.

However, recently she began receiving program statements again. It seems that number has been reissued, and the new owners have this long distance carrier, but have NOT signed up for the "Mile-A-Minute" program.

When reassigning a number, all features should have been reset to their defaults. In this case, they were obviously not. The total 'cash' value (at $.03 per mile) of the error is not very significant. A more serious risk is that my sister receives a detailed billing report every month, listing the number called and the call duration for each qualifying number. It is sent to the address listed on her frequent flier account, and not to the billing address of the new owners of the line.

In addition to eliminating 'old' data, such systems need to take into account the nature and sensitivity of data disclosed on such statements.

Jonathan Clemens, jclemens@aa.net

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

Date: Sat, 7 Dec 1996 19:35:02 +0000 From: robert@justine.dgsys.com Subject: Year 2000 and expiration dates

Today, I had my first encounter with the year 2000 problem. I took my shiny new, already activated, Visa cheque card into Citibank, Manhattan branch and after inserting the card into the validation machine the teller told me my card had expired. My expiry date is 01/00. A few moments later I had successfully convinced that teller that the card couldn't have been issued in the 1800's and so he phoned a verification service to check. That service also declined the card. It wasn't until I had called my own bank and asked them to turn off all security checks on the card that I could successfully obtain my cash advance.

I had earlier dismissed all the hype surrounding the year 2000 problem thinking that most corporations would have already made the necessary changes to cope. Considering it's typical for cards to be issued for 4 year periods it's not surprising to see a card issued in 1996 suffering this problem. I can only hope things improve as we approach 2000.

Robert Nicholson <robert@elastica.com>

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

Date: 3 Dec 1996 18:43:51 GMT From: darin@connectnet1.connectnet.com (Darin Johnson) Subject: Centralized computing

A few months back, I was shopping at a Computer City, a large chain of PC stores of the sort that caters to the mass market. When I got to the front of the checkout line (which is normally slow to begin with), things came to a halt. Apparently, all transactions were handled by computer, and it was down.

OK, I thought they've got a backup in the back, and it'll kick in, or the thing will reboot. No good. After awhile, one of the clerks reported that the computer that was down was in LA (I was in San Diego). All their transactions were being handled remotely, and for all the computers and manpower they had locally, they couldn't do anything but wait.

Later still, someone came back up front with a book describing how to do checkouts manually. None of the clerks knew. When I was checked out, it took four people, one to be in charge, one to use the calculator to compute tax and total, one to verify my credit card, and one to read the instruction book.

I was struck by two ironic facets of all this. First, the reliance upon centralized computers. The PC got its big start and popularity run initially by allowing independent computer use away from centralized MIS departments. Have things come full circle again, away from independent computers to centralized ones? It would not have been unreasonable for a computer seller to have an extra backup computer in back, something to process transactions locally and then transmit them remotely later. Perhaps the risk here is forgetting history (not to stereotype too blatantly, but I see a distinct lack of historical computer knowledge in much of industry).

The second facet is the old risk of becoming too dependent upon technology. Requiring four people to check out one small purchase is excessive, and all because none were trained to do such things manually (not to stereotype too much again, but they didn't seem to be trained that well in computers either :-). On the other hand, I can go into grocery stores and have the checkers rapidly process a large purchase, knowing the price of each item; I've had other stores take only one person to fill out receipts by hand when power was out. Why would a computer store be so crippled by a remote computer being down, were they even more dependent upon technology than other stores?

Darin Johnson darin@connectnet.com

[Yes, this is an old tale for RISKS readers. But did you think a computer store would know better? PGN]

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

Date: Wed, 4 Dec 96 14:28 EST From: Perillo@DOCKMASTER.NCSC.MIL Subject: Re: Bell Atlantic 411 outage (RISKS-18.63)

This was not a complete outage, but about 60% of the Bell Atlantic company's 2,000 operator's at 36 sites could not log into their automated directory system. Of the 40% that were able to access the database, lookup times went from the typical 19 seconds into minutes. The problem manifested itself about 8am on Monday November 25th, and was fixed about seven hours later by reloading the previous version of the database software. But this was the most extensive directory-assistance failure since telephone operators started using computers, affecting hundreds of thousands of customers in nine eastern states.

Originally Bell Atlantic blamed the problem on a "software glitch" in the "Nortel Directory One" database software upgraded over the weekend. Northern Telecom stated that the new software, which was meant to correct minor errors in the previous version, was being used by several large phone companies without any problems. The problem seems to have been traced to a Nortel technician who improperly installed the software on two RS/6000 servers. The incorrect installation of the main database, also somehow caused the same type of access problems on the duplicate/backup database system.

While RISKS has concentrated on software errors, installing software into operating systems has gotten increasingly complex, usually done by non-degreed technicians and operators, following informal instructions scrawled on the back of napkins. In this case it seems that since the malfunction was load related, the technician was unaware during system checkout that the database was incorrectly installed. More scrutiny should be given to software installation, and installation procedures or possible problems. Formal procedures with Quality Assurance (QA) checklists should be used. Could automated installation programs, or problem checking software, be used to prevent or detect installation problems?

References: "Software Glitch Snarls Bell Atlantic's 411 Calls", Washington Post, 11/26/96, page D1 .

"Bell Atlantic Customers Are Put on Hold by Directory Assistance", New York Times, 11/26/96, page A17.

"Software Glitch Hits Bell Atlantic Sites", InformationWeek, 12/2/96, page 32.

Robert J. Perillo Staff Computer Scientist Perillo@dockmaster.ncsc.mil

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

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 <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] => 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>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.65 ************************