precedence: bulk Subject: RISKS DIGEST 19.53 RISKS-LIST: Risks-Forum Digest Tuesday 6 January 1998 Volume 19 : Issue 53 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: Sun Valley ski area forgets to back up (David Kipping) Debit-card program cancelled because of fraud (Steve Bellovin) Japanese bank records stolen (Steve Bellovin) Easter Eggs in Commercial Software (Larry Werring) Pharmacy computer keys on names, mixing confidential records (anonymized) MCImail spam blocker adds to woes (Michael M. Krieger) Spammers blackmail AOL (Stephan Somogyi) Sending the wrong message with flowers (Bear Giles) Re: What really happened on Mars Rover Pathfinder (Ken Tindell, Fred Schneider) Re: Adjust your defibrillator (Richard Cook) Re: Has Microsoft already infected itself? (David M. Chess, Eric Cholet) ERCIM-FMICS 3 - Call for papers (Diego Latella) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 24 Dec 1997 12:09:16 -0500 From: David Kipping Subject: Sun Valley ski area forgets to back up The Sun Valley ski area in Idaho has a high-tech ticketing system. You buy a season discount pass for a small fee and get a card with photo and bar code. To ski you then pay for the day (at a discount). There is no paper ticket as all information is in the ticketing computer. When you are ready to get on the ski lift, an attendant scans your pass with a hand-held terminal, your bar code is sent to the ticketing computer by radio, the computer validates that you have paid for the day, and the result is sent back by radio to the hand-held terminal. All this happens in less than a second. The pass database is built up over several months as passes are sold. During the week of 14 Dec 1997, the hard disk on the ticketing computer failed and the ticketing database was destroyed. The computer hardware was quickly repaired, but there was no backup for the ticketing database. All pass-holders (several thousand) are required to come to the Sun Valley offices where personal data is re-entered, new photos are taken, and new passes are issued. ------------------------------ Date: Sun, 28 Dec 1997 09:22:45 -0500 From: Steve Bellovin Subject: Debit-card program cancelled because of fraud According to the AP, Burns National Bank (Durango, CO) is cancelling its debit-card program because of fraud. The article is maddeningly incomplete about technical details. Apparently, the "hackers" (to quote the article) counterfeited plastic cards and "took account number sequences off software that resides on the Internet before encoding them in the magnetic strip on the back of the card." When the fraud was detected, some customers had new cards issued, with some unspecified extra security feature. It didn't work; within a month, the accounts were penetrated again. Three other banks have been victimized by a similar scheme. All four use the same debit card vendor; Burns blames the vendor for inadequate security, in some unspecified form. They're looking for a new supplier; until then, the entire program is being suspended. Losses to date -- which are apparently being absorbed by the banks -- total $300,000. ------------------------------ Date: Mon, 05 Jan 1998 11:40:15 -0500 From: Steve Bellovin Subject: Japanese bank records stolen Reuters reports (http://www3.zdnet.com/zdnn/content/reut/0105/268074.html) that a Japanese bank's computer records were penetrated. Data on some customers, including names, addresses, and birthdays, was taken. The bank says that the problem likely occurred because of a software upgrade last year. It declined to release any further details about the software. An AP report on the incident said that an employee with the firm doing the software upgrade allegedly offered the data to a mailing-list company. That company alerted the bank, saying that the data -- which included financial information -- was "too detailed". ------------------------------ Date: Mon, 5 Jan 1998 12:29:09 -0500 From: EM3405@cgi.ca (Larry Werring) Subject: Easter Eggs in Commercial Software Do you know what kind of hidden features are hidden in commercial applications? Do you know how much disk space is wasted as a result of these hidden applications (known as Easter eggs) within commercial applications? What do Easter eggs have to say about project management, quality control and configuration management of the company developing products containing the Easter eggs? How much extra is the consumer paying for products to cover the cost of developing these hidden and utterly useless applications? How much time is being wasted by employees at the expense of their employer (usually the customer who paid for the application) to look for and play with these Easter eggs? What other unknown features are embedded within commercial products? Can you trust any commercially developed product? What follows are two examples of Easter eggs hidden within commercial applications (I have used Microsoft products only to demonstrate how elaborate an Easter egg can be). Example 1: Open Excel 97. Open a new worksheet and press the F5 key. Type X97:L97 and press the Enter key. Press the Tab key. Hold Ctrl-Shift and click the Chart Wizard button on the tool bar. Once the Easter egg is activated, use the mouse to fly around - right button for forward, left for reverse. Note: If you don't have DirectX drivers installed you will only get a list of developer names. If you do, you will encounter a flight simulator. Can you find the focal point of the virtual region with the scrolling display? Example 2: Open Internet Explorer. Select "About Internet Explorer" from the help menu. Hold down the Ctrl key and use the mouse to select and drag the "e" in the upper right hand corner onto the picture of the Earth and release the Ctrl key. Hold down the Ctrl key again and use the mouse to drag the "e" so that it pushes the words "Microsoft Internet Explorer 4.0" out of the way and return the "e" to the planet earth. If it hasn't already started to run, press the "unlock" button to see a display of all the IE 4.0 development team. Note: This Easter egg is lengthy. The author has attempted to interject humour at various points in the display but has failed miserably. In fact, the author admits to a crime committed by one or more members of the team (theft of construction sign - remember the teenager convicted of multiple counts of manslaughter for stealing a traffic sign). Also, at the very end of the display, the author impugns the character of several team members (basis for possible defamation of character suit by the individuals?). I'll bet that this Easter egg was never approved by the IE 4.0 project manager or Bill Gates. So-called Easter Eggs are hidden within many Microsoft applications (Windows 95 and NT, for example). However, other products apparently have them as well (e.g. Netscape and Macintosh System 7.5 for example). I remember the days when every line of code was examined before we would allow a program to be used in a trusted environment. This was deemed too expensive so now we "trust" software creators. How can you "trust" any commercial product sold by a major manufacturer when it can be demonstrated that many products from the manufacturer include hidden applications and possibly functions as part of the product. Note: I addressed an e-mail about this to Microsoft's Security guru's but, as usual, got nothing back but an acknowledgement of receipt. Larry Werring, IT Security Consultant ------------------------------ Date: Weds, 24 Dec 1997 From: [identity withheld by request] Subject: Pharmacy computer keys on names, mixing confidential records I suffer from an embarrassing medical condition, treatable only by expensive medication that has no other uses in adults. If you buy the medication, in other words, you probably have the condition. My doctor phoned a prescription in to the local CVS. Ninety minutes later, I showed up to collect it. I told the pharmacist my name, and she handed me the medication. She then told me my insurance had expired in January 1997, and I would therefore have to pay the full price. I explained to her that my insurance (through an HMO) is very much in force but doesn't cover drugs, and that she obviously had bad information, presumably from CVS' computers. Both my given name and surname are fairly common in the U.S.A.; there are at least four others with my first and last names in the local area. She refused to believe me at first, changing her mind only when I pointed out that it wasn't my address her computer had printed on the receipt. She then took back the medication, asked for my name, date of birth, address, telephone number, and medical allergies. Irked, but wanting to avoid a fight, I tendered information to her satisfaction, paid for the medication, and left the store. Apparently, when the prescription came in, CVS simply assumed that it must have been for the person with the same name already in their system. I can think of at least five risks of this sloppy system: 1. If the other guy's insurance hadn't expired, I could have scammed free or nearly-free medication on his (insurance's) dime. 2. If I hadn't asked what was going on, his records at CVS would show that he obtained medication for an embarrassing medical condition. 3. Since I'm quite certain the CVS technician didn't call back to disabuse them, his old insurance now thinks he obtained medication for an embarrassing medical condition. If I had been getting the equally distinctive drugs for HIV, such a disclosure could have quite serious consequences for the poor sap. 4. CVS' database includes information on patients' allergies to medication. The pharmacist didn't ask me whether I had any allergies until after I established that she was working from the wrong record. Their vaunted system for tracking patients will not work to the extent they are mixing up people with the same name. 5. Immediately distrustful of CVS, I gave the pharmacist a false address, phone number, and date of birth. Now there are five locals with my first and last name. Silver lining: at least they don't key on the Social Security Number. [... although that can beneficially disambiguate... PGN] ------------------------------ Date: Thu, 25 Dec 1997 22:26:39 -0500 (EST) From: "Michael M. Krieger" Subject: MCImail spam blocker adds to woes MCI Mail's new anti-spam filter option depends on a non-optional system change MCI's Internet gateway makes to subscriber addresses when sending outbound messages; this yields undesirable consequences, perhaps worse than the original spam problem. In particular, MCI Mail created a (probability ---> 1.0) Risk of its users being sitting ducks for spammers when it switched to sequentially assigning the traditional seven digit 123-4567 address/ID's to new accounts (in lieu of spacing them out). This allows automated spam addressing, e.g., the Internet addresses <123-4567@mcimail.com>, <123-4568@mcimail.com>, ... To overcome this, MCI Mail recently gave its users the option to block numerically addressed messages (e.g., <597-5596@mcimail.com> in my case), while making a new acceptable address format. Because "username" (which is a user's logon, e.g., "jsmith") is not public (nor susceptible to automated deduction from the 7-digit address), over-spammed MCI Mail users can invoke the filter while giving to friends and other correspondents. All well so far. But "to complement the new filtering capability," MCI Mail now converts (NON-optionally) its members' addresses to the new format when messages exit the gateway into the Internet "so that if you did invoke the filter, your correspondents could still use their "reply" function and capture your address in a way that won't be impacted by the filter. This change will take effect on Nov. 24." [quotes from MCI Messaging Notification, to Users on 12 Nov 1997] Oops! Shouldn't this have been optional too? Might not an MCI Mail user's intended Internet recipient have him/herself already implemented blocking rules or filtering mechanism which will reject as unknown? The obvious Risks are failed messages (some of which likely won't even yield rejection notices) and corresponding business and personal loses, the burden of resubscribing to listservs which can no longer recognize you, etc. Moreover, in the future changing a "username" will mean resubscribing to lists, and other administrative overhead. Good way to drive off customers. Perhaps most detrimentally, this forces the user's "username" into the clear. Although MCI Mail defaults new users to "jsmith" format, that can be changed arbitrarily to anything, e.g., "smartestjsmith." One might wish to keep it private (account logon is the "username" and, if unique within the MCI Mail system, "username" can also replace 123-4567 within MCI Mail, as part of Internet addresses, etc.). Finally, with time listmakers and spammers will capture many "username"'s after which they will be even more difficult for users to elude than before! Michael M. Krieger ------------------------------ Date: Wed, 31 Dec 1997 16:31:30 -0500 From: Stephan Somogyi Subject: Spammers blackmail AOL [Via the IP list of Dave Farber ] CNN's been reporting this on Headline News today, but no reference to it on their Web sites. However, the LA Times has the following on the subject: <http:// www.latimes.com/HOME/NEWS/BUSINESS/UPDATES/lat_aol1231.htm> Stephan A small snip of the LA Times article: The opposing interests of electronic commerce and individual privacy erupted in conflict Tuesday after a small Internet business group threatened to make public the e-mail addresses of 1 million of America Online's 10 million users if the giant service continues to bar the businesses from pitching their products online to AOL members. The Chino-based National Organization of Internet Commerce said it would post the e-mail addresses on its own Web site at the stroke of midnight Wednesday, making them available for downloading by any business, group or individual seeking to make mass electronic mailings. The organization said it would leave the names posted for 24 hours unless AOL offered small businesses a way to reach its 10 million members through inexpensive electronic means. ------------------------------ From: Bear Giles Subject: Sending the wrong message with flowers Date: Fri, 2 Jan 1998 15:39:57 -0700 (MST) At the FTD website (www.ftd.com), the links for "get well" and "funeral" arrangements are adjacent. No problem with new mice driven by someone under no stress, but with an older mouse and frazzled nerves it would be easy to click "funeral" instead of "get well" -- something that would not be pleasant for the viewer. The risk is that page layout for interactive media is different than non-interactive media. Something which works well, when simply read, may have serious flaws when it requires a person to interact with it in real-world conditions. Bear Giles ------------------------------ Date: Fri, 12 Dec 1997 19:16:15 -0000 From: Ken Tindell Subject: Re: What really happened on Mars Rover Pathfinder (Jones, R-19.49) >This scenario is a classic case of priority inversion. So classic that it has happened before many times in many projects. And I fear will continue to happen. Today, people are building critical real-time systems based on Windows NT. But NT doesn't implement priority inheritance. Instead it contains a "priority randomizer" which randomly selects tasks and alters their priorities in the hope that eventually the priority inversion goes away. Whilst this may be adequate for a general-purpose computer in a workstation environment, this is unlikely to be adequate for a critical real-time system. >For the record, the paper was: >L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An >Approach to Real-Time Synchronization. In IEEE Transactions on Computers, >vol. 39, pp. 1175-1185, Sep. 1990. I must point out that their work appeared much earlier in technical reports and conference proceedings and was widely cited before the 1990 paper appeared. Interested readers might like to read the following paper, which gives an historical perspective on when major results were made available: "Fixed Priority Scheduling: An Historical Perspective", Audsley, Burns, Davis, Tindell, Wellings, Real-Time Systems journal, March 1995, Volume 8, No. 2/3, pp. 173-198. I find it outrageous that engineers in 1997 are building critical systems that contain serious defects that were detectable and correctable ten years ago. I do wonder at what point failure to be aware of these risks constitutes negligence. ------------------------------ Date: Mon, 5 Jan 1998 18:29:27 -0500 (EST) From: "Fred B. Schneider" Subject: What really happened on Mars Rover Pathfinder (Mike Jones, R-19.49) Readers of RISKS could get the wrong impression about who did what and when from what David Wilner is reported to have said in Mike Jones' item on the Mars Pathfinder mission in RISKS-19.49. This note attempts to provide some missing information. Jones' Mars Pathfinder article ends with: "THE IMPORTANCE OF GOOD THEORY/ALGORITHMS David [Wilner] also said that some of the real heroes of the situation were some people from CMU who had published a paper he'd heard presented many years ago who first identified the priority inversion problem and proposed the solution. ... For the record, the paper was: L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An Approach to Real-Time Synchronization. In IEEE Transactions on Computers, vol. 39, pp. 1175-1185, Sep. 1990." Actually, a "priority inheritance" protocol can be found in B. W. Lampson and D. D. Redell. Experience with processes and monitors in Mesa. {\it Communications of the ACM}, vol. 23, no. 2, pp. 105--117, February 1980. which is a reprint of a paper that appeared in Dec 1979 (7th ACM Symposium on Operating System Principles). Below is the relevant excerpt; it is almost -- but not exactly -- what Sha et al. investigate. "4.3 Priorities In some applications it is desirable to use a priority scheduling discipline for allocating the processor(s) to processes which are not waiting. Unless care is taken, the ordering implied by the assignment of priorities can be subverted by monitors. Suppose there are three priority levels (3 highest, 1 lowest), and three processes P_1, P_2, and P_3, one running at each level. Let P_1 and P_3 communicate using a monitor M. Now consider the following sequence of events: P_1 enters M P_1 is preempted by P_2 P_2 is preempted by P_3 P_3 tries to enter the monitor, and waits for the lock P_2 runs again, and can effectively prevent P_3 from running, contrary to the purpose of the priorities A simple way to avoid this situation is to associate with each monitor the priority of the highest-priority process which ever enters that monitor. Then whenever a process enters a monitor, its priority is temporarily increased to the monitor's priority..." So, it would be incorrect to credit Sha et al. for first *identifying* the problem or for first *proposing a protocol* to solve it. Lampson & Redell do not give any quantitative analysis of their prio scheme, though. The development of this thread of research in real-time scheduling is accurately described in section 5 of Audsley et al., as noted by Ken Tindell. A parable comes to mind. School children in the U.S. are taught that "Columbus discovered America". Ultimately they learn that Columbus was preceded by, among others, the Vikings. So why aren't they taught that "The vikings discovered America"? Perhaps it is because when Columbus discovered America, it stayed discovered. ------------------------------ Date: Fri, 26 Dec 1997 08:40:50 -0600 From: Richard Cook Subject: Re: Adjust your defibrillator (McGraw, RISKS-19.52) Gary McGraw seems surprised that implantable defibrillators can be externally programmed and hopes that there are some safety mechanisms available to prevent unintended or maliciously intended reprogramming. I encounter these devices in my daily practice and want to provide a little background for other readers of RISKS. Actually, these devices are pretty much the definers of what is the state of the art in medical electronics. I know of no other information technology in medicine (including all the monitoring and lab system technology that we have studied and written about over the years) that has anything like the reliability and robustness of heart pacers and defibrillators. It may be interesting for readers to know that, until very recently, the only way one could become a candidate for an implantable defibrillator is to have had a documented episode of sudden cardiac death, i.e. to have had ventricular fibrillation. Needless to say, this kept the potential recipient pool small: few people survive the initial event! The devices have a number of features that are tuned to individual patient characteristics, and they are re-tuned over time. What one is trying to do is to assure that the device will sense fibrillation and fire but not fire when fibrillation is not actually present. It can be uncomfortably startling to be defibrillated when nothing is really going on, and these devices have lots of program dedicated to making sure that a shock is really indicated. For this reason, programming of the devices is an essential feature -- you can't really use them effectively without being able to interrogate them, reset various features and tune them in a number of ways. Gary's claim that this is a source of risk is surely true, and it is one (but only one) reason that the guys who make these things are so heavily invested in reliability and safety. In fact, I suspect that this sort of device is less a model of what can go wrong and more a model of what actually can be done well not only in medical devices but with technology in general. But it is always useful to keep in mind that the people walking around with these things have already had at least one major lesson in coping with risk! This is the only device, besides a coffin, that I know of that you have to die to get! Cognitive Technologies Laboratory Richard I. Cook, MD, Department of Anesthesia and Critical Care, University of Chicago; 5841 S. Maryland Ave., MC 4028; Chicago, IL 60637 1+773-702-5306 ------------------------------ Date: Tue, 6 Jan 98 09:19:49 EST From: "David M. Chess" Subject: Re: Has Microsoft already infected itself? (Brown, RISKS-19.52) > Can anyone explain what this string is doing in WWINTL32.DLL That is a string that occurs in the "DMV" Word macro virus. It is present in that DLL almost certainly in order to allow Word for Office 97 to recognize that virus in infected Office95-format files, so that it can avoid bringing the virus along when it converts to Office 97 format. There are a number of different virus-fragments in that DLL. (This has in fact led to a certain amount of confusion. It is accepted practice in the anti-virus community to always mask or otherwise trivially encrypt such virus search-strings so as to avoid false positives and user suspicions; that was not done in this case, obviously.) Knowing too much, too obviously, about the enemy is often enough to get you suspected yourself... *8) David M. Chess, High Integrity Computing Lab, IBM Watson Research [Also commented on by Eric Florack . PGN] ------------------------------ Date: Wed, 24 Dec 1997 20:02:14 +0100 From: Eric Cholet Subject: Re: Has Microsoft already infected itself? (Brown, RISKS-19.52) Well, I examined my copy of the same file, and found a bunch of such strings: You have been infected by the Alliance This one's for you, Bosco echo y|format c: /u STOP ALL FRENCH NUCLEAR TESTING IN THE PACIFIC! Parasite Virus 1.0 InfectorPayLoad Where's the Gerbil of bubby? Now, where's that Gerbil of bubby? Hi sexy! Description : On FileOpen, detect documents masquerading as templates, warn user and optionally restore them to documents My guess is that they're simply virus signatures used by Word's macro virus detection code. Still, where's the Gerbil of bubby ? Eric Cholet ------------------------------ Date: Mon, 5 Jan 1998 15:46:27 +0100 (MET) From: Diego Latella Subject: ERCIM-FMICS 3 - Call for papers FIRST CALL FOR PAPERS Third ERCIM International Workshop on Formal Methods for Industrial Critical Systems (FMICS) Centrum voor Wiskunde en Informatica (CWI) CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands May 25-26, 1998 The First International Workshop on Formal Methods for Industrial Critical Systems took place in Oxford on March 19, 1996, and the second edition was held in Cesena on July 4-5, 1997. The Third International Workshop will take place in Amsterdam on May 25-26, 1998. The aim of the FMICS workshops is to provide a forum mainly intended for, but not limited to, researchers of ERCIM sites, who are interested in the development and application of formal methods in industry. In particular, these workshops should bring together scientists that are active in the area of formal methods and interested in exchanging their experiences in the industrial usage of these methods. They also aim at the promotion of research and development for the improvement of formal methods and tools for industrial applications. Please notice that the FMICS workshop will be held in the same week as the ICDCS98 conference, which will also be held in Amsterdam. Authors are invited to send five copies of a full paper (in English, up to 25 pages) to the Programme Chair: J.F. Groote, CWI, P.O. Box 94079, 1090 GB Amsterdam, The Netherlands by February 15th, 1998. An electronic version of the paper in Postscript format plus an abstract should also be sent to: jfg@cwi.nl. INVITED SPEAKERS include W.J. Fokkink - University of Swansea - UK G. Kolk - Holland Railconsult - NL S. Smolka - State University of New York - Stony Brook, USA PROGRAMME COMMITTEE: J.F. Groote - CWI - NL (Chair) F. Gnesi - CNR/IEI - Pisa, IT D. Latella - CNR/CNUCE - Pisa, IT R. Mateescu - CWI - NL A. Poigne - GMD - Bonn, G J. Tretmans - University of Twente - NL Informal participant proceedings will be distributed at the workshop. Deadline for submission: 15 February 1998 Up-to-date information will appear at http://www.cwi.nl/~luttik/FMICS/index.html ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] 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 19.53 ************************