RISKS-LIST: RISKS-FORUM Digest Friday 26 January 1990 Volume 9 : Issue 62 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Australian medical database linkages (Michael Bednarek) Cause of AT&T network failure ("Telephony", Jim Harkins) London Stock Market Disruption (courtesy of Steve Milunovic) Railway interlocking (Clive Feather) More risks to computers (Richard Thomsen) Re: Risks of supermarket checkout scanners (Marvin Moskowitz, Doug Renner, Don Craig) Robert T. Morris Convicted (Michael J. Chinni) Advance Program for Oakland Symposium (REVISED) (Debbie Cooper) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]get risks-i.j . Vol summaries now in risks-i.0 (j=0) ---------------------------------------------------------------------- Date: Tue, 23 Jan 90 13:32 +1100 From: Michael Bednarek, Melbourne University Subject: Australian medical database linkages Database `akin to ID card' by Tony Healy (The Australian, 23-Jan-1990) Incensed pharmacists have forced the deferral of a nationwide computer network which they say has many features of the Australia Card. [A national ID card scheme whose introduction was recently abandoned] According to confidential documents obtained by _The Australian_, the proposed network will record every medical prescription issued to every individual and family in Australia during long periods of time. It will thus form a detailed and easily accessed record of personal illness and disease. Although the network has received little publicity, it was originally scheduled to start operating on a pilot basis in April and to be fully operational by the end of the year. It is to be implemented by the same government body that wanted the Australia Card -- the Health Insurance Commission -- using the same computers it bought for the Australia Card. Most controversial of all is the commission's intention to link its database with that of the Department of Social Security. This intention is explicitly stated in the documents held by _The Australian_ -- a Health Insurance Commission report titled Strategy Proposal for the Management of the Pharmaceutical Benefits Program. In the report, the commission also proposes making its network available on a commercial basis to pharmaceutical suppliers. Such a link realises the worst fears of civil libertarians, who contend that the centralisation of information and high speed access exposes information to abuse. Both the Pharmacy Guild and the Australian Medical Association (AMA) have objected to the risk this poses to patient confidentiality. Guild protests forced the commission to postpone the introduction of the network by six months., its president, Mr Jim Mathews, said. The federal president of the AMA, Dr Bryce Philips, said the association has sought formal assurances from the commission that patient confidentiality can be guaranteed. "If it can't, we will not be part of it," he said. A pointer to the furtiveness surrounding the network is that the AMA learned about it only by chance late last year, Mr Mathews said. In its report, the Health Commission also states its intention to create a culture in which people carry an identifying card. Confidential tender documents issued by the commission call for the network eventually to be able to accept magnetic stripe cards. In addition, the commission recently tried to expand the information it gathers from concession application forms. Pharmacists point out that the extra information gives the Government the same information it wanted to record on the Australia Card and have refused to provide it. The rationale behind the network is to reduce an estimated $[AUS]30 million worth of pharmacy benefits fraud identified in report by the Attorney General. The network will consist of online terminals in each of Australia's 5500 pharmacies, connected to a central database running on the commission's two IBM 3090 mainframes. Before issuing prescriptions, pharmacists will be required to check all customers on the computer. A principal reason is their eligibility for pensioner and other concessions -- this concerns about 80 per cent of prescription customers. A spokesman for the Federal Minister for Community Services, Mr Staples, denied the claims and described them as part of pharmacists' heated campaign against the Government. Michael Bednarek, Big River Ski Lodge Caravan Park, Seelands via Grafton NSW 2460, Australia, Phone: +61 66 {44 9324 | 44 9200} u3369429@{murdu.oz.au | ucsvc.dn.mu.oz.au} | mb@munnari.oz.au [Also submitted by ph@wolfen.cc.uow.oz.au (Rev Dr Phil Herring) ] ------------------------------ Date: Fri, 26 Jan 90 14:24:30 PST From: "Peter G. Neumann" Subject: Cause of AT&T network failure From Telephony, Jan 22, 1990 p11: "The fault was in the code" of the new software that AT&T loaded into front-end processors of all 114 of its 4ESS switching systems in mid-December, said Larry Seese, AT&T's director of technology development. In detail: The problem began the afternoon of Jan 15 when a piece of trunk interface equipment developed internal problems for reasons that have yet to be determined. The equipment told the 4ESS switch in New York that it was having problems and couldn't correct the fault. "The recovery code is written so that the processor will run corrective initialization on the equipment. That takes four to six seconds. At the same time, new calls are stopped from coming into the switch." Seese said. The New York switch sent a message to all the other 4ESS switches it is linked with that it was not accepting additional traffic. Seese referred to that message as a "congestion signal." After the switch successfully completed the reintialization, the New York switch went back in service and began processing calls. That is when the fault in the new software reared its ugly head. Under the previous system, switch A would send out a message that it was working again, and swithc B would double-check that switch A was back in service. With the new software, switch A begins processing calls and sends out call routing signals. The reappearance of traffic from switch A is supposed to tell switch B that A is working again. "We made an improvement in the way we react to those messages so we can react more quickly. The first common channel signaling system 7 initial address message (caused by a call attempt) that switch B receives from swithc A alerts B that A is back in service. Switch B then resets its internal logic to indicate that A is back in service," said Seese. The problem occured when switch B got a second call-attempt message from A while it was in the process of resetting its internal logic. "[The message] confused the software. it tried to execute an instruction that didn't make any sense. The software told switch B `My CCS7 processor is insane'", so switch B shut itself down to avoid spreading the problem, Seese explained. Unfortunately, switch B then sent a message to other switches that it was out of service and wasn't accepting additional traffic. Once switch B reset itself and began operating again, it sent out call processing messages via the CCS7 link. That caused identical failures around the nation as other 4ESS switches got second messages from switch B while they were in the process of resetting their internal logic to indicate switch B was working again. "It was a chain reaction. Any switch that was connected to B was put into the same condition." "The event just repeated itself in every [4ESS] switch over and over again. If the switches hadn't gotten a second message while resetting, there would have been no problem. If the messages had been received farther apart, it would not have triggered the problem." AT&T solved the problem by reducing the messaging load of the CCS7 network. That allowed the switches to rest themselves and the network to stabilize. ------------------------------ Date: 23 Jan 90 12:39:43 PST (Tue) From: jharkins@sagpd1.UUCP (Jim Harkins) Subject: Re: AT&T Failure WHMurray.Catwalk@DOCKMASTER.NCSC.MIL [WHMurray@DOCKMASTER.ARPA] says >The assertion by AT&T, "in an effort to allay customer fears about the networks >reliability," that the outage was "traced to a single computer program," not >only fails to reassure me, but alarms me greatly. It suggests a serious >failure on their part to understand the nature of the problem. I think you need to remember that this failure report was intended for the great unwashed, who relate the term 'computer' to their Apple II, or possibly the protagonist in the movie 'The Demon Seed'. It is clearly inadaquate for those of us who are technically literate. I for one am looking forward to reading in Risks and similar technical journals what really happened. jim ------------------------------ Date: 26 Jan 90 09:37:59 From: Steve Milunovic Subject: London Stock Market Disruption Trading on the London Stock Exchange suffered a minor disruption on 23 Jan 90 when a computer problem interrupted the quotation of the stock exchange market indexes for two hours and 20 minutes. The problem was spotted when The Financial Times-Stock Exchange index of 100 leading stocks suddenly went from a slight gain to a noticeable loss. The exchange shut down the index service at noon, installed a standby computer and began operating the service again at 2:20 p.m. The exchange's automated computerized trading system was not affected, and individual stock quotes were accurate. [Source: N.Y. Times News Service, 23 Jan 90] ------------------------------ Date: Tue, 23 Jan 90 10:08:23 gmt From: Clive Feather Subject: Railway interlocking I felt I had to say a few things about Douglas Jones' item in RISKS 9.58. Whilst I realise that UK and US usages may be different, I think that some of these points may be of interest to all readers anyway. > (One at a time because it takes his full strength ...) Some levers control the signal or points electrically, and so require almost no effort. For this reason, the lever handle is cut short so that only one hand can be used on the lever. Nevertheless, the signalman will only operate one lever at a time. In large boxes, two or three signalmen may work a single frame ("frame" is the UK term for the row of levers). In this case, it is possible for two or more levers to be operated at the same time. This was a contributing factor to the accident at Hull (Paragon). [Note to PGN: msb@sq.com mailed you and me a description of this about two years ago. If you or he still has it, it might be worth posting it to RISKS.] > (I've seen photos ... with banks of 20 or more control levers.) In the UK, 20 levers would be regarded as a small frame (and so low paid!). A typical main-line box would have 50 to 60 levers, and a large one could have two frames of 120 levers each. This makes the interlocking problem considerably more complex. > ... thus, there are 256 possible states of the system. > An interlocking machine consists of a set of 8 transverse rods crossing 8 > rods linked to the control levers. It would be unusual for there to be exactly 8 transverse rods, or "tappets" as they are known. Each tappet implements one condition in the interlocking. It is not sufficient to consider the static states, as there are many circumstances when a *change* must be forbidden (e.g. don't move 2 if 1 is up, even though either state of 2 is legal when 1 is up). In the example given, the conditions, one per tappet, would be: 1, 3, 4 down to move 2 5, 6, 8 down to move 7 3 up only if 2 set to straight through 4 up only if 2 set to loop 5 up only if 7 set to straight through 6 up only if 7 set to loop 1 up only if 3 and 4 down 8 up only if 5 and 6 down 1 and 8 cannot both be up Thus 9 tappets would be required. (The last condition implements a general rule that trains are never allowed into a passing loop from both directions at the same time). (Of course, this layout would not be implemented as such. Firstly, the points would have locks, each controlled by their own lever. Secondly, two further signals would be placed at the same locations as 1 and 8, but applying in the opposite direction, so that a train can be shunted between the two sides of the loop without leaving the area controlled by the signal box. Thirdly, these two signals would be electrically interlocked with equipment which ensures that a train cannot be signalled on to a single line which is already occupied. Fourthly, there would be distant signals about a mile before 1 and 8, which show only "caution" and "clear"; these could only show clear if the points are set for straight through running, and all signals in that direction are at "go". Finally, a King lever would be installed to allow the box to be unmanned at night; when the lever is pulled, it is possible to clear the signals in both directions at the same time, notwithstanding the interlocking, and the signal boxes on either side would be connected to each other as if this one was not there. So in fact we would have 13 levers, probably about 18 tappets (I haven't worked it out), and some electrical interlocks (see below). But this is starting to sound like rec.railroad :-) Modern practice in lever frames (which are slowly being phased out) is to use electrically controlled bolts as well as or instead of tappets to lock the levers. This allows practices such as: - don't allow a signal to be raised without permission from the next signal box down the line; - ensure that permission applies for "one pull only", and that the signal must be replaced before permission can be given again; - only allow the exit signal to be raised if a "token" has been issued for the single line section ahead; two signal boxes are connected so that only one token can be issued at a time (the token may be physical or logical); - ensure that a train has occupied and cleared a specific track circuit before the signal can be cleared again ("Welwyn control"). The Farnley Junction accident (RISKS-5.66, 30 Nov 87) shows that safety critical software problems are nothing new (the accident occurred because NOT NOT X equals X), and railways do indeed have something to teach us. Clive D.W. Feather, IXI Limited ...!uunet!ukc!ixi!clive (riskier) ------------------------------ Date: Mon, 22 Jan 90 08:25:52 MST From: rgt%beta@LANL.GOV (Richard Thomsen) Subject: More risks to computers A friend of mine worked as a computer operator in a company with a large IBM computer. One day, they called in the repairman for a faulty console. When the repairman arrived to check out the problem, he noticed that some of the keys of the console keyboard were stuck down, in the shape of a closed fist. His comment: "We can fix this, but it will not be under warranty." Richard Thomsen ------------------------------ Date: 22 Jan 90 23:47:21 GMT From: marvinm@ttidca.TTI.COM (Marvin Moskowitz) Subject: Re: Risks of supermarket checkout scanners (Marks, RISKS-9.61) >I seems to me that consumers accept the technology not because they feel >it is accurate, but because it makes checkout faster. It seems to me that consumers accept the technology because they have no choice. The only markets in Los Angeles that DON'T use automated scanners are small convenience stores (e.g. 7-11). If you want to buy food, you HAVE to accept the scanner system. My wife has objected to the lack of marked prices, preventing her from checking the receipts. I have suggested she take a pen to the market and mark the prices as they come off the shelf. The only problem is a fair percentage of the shelf prices are missing, which I imagine IS a violation of some law. Go tilt at windmills! Marvin S. Moskowitz, Citicorp/TTI, 3100 Ocean Park Blvd.,Santa Monica, CA 90405 (213) 450 9111 x3197 {philabs|csun|psivax}!ttidca!marvinm ------------------------------ Date: Tue, 23 Jan 90 11:48:30 CST From: elec@pnet51.orb.mn.org (Doug Renner) Subject: Re: risks of supermarket checkout scanners It may very well be the case that people accept the technology because they feel it is more accurate. The real issue is that this 'feeling' may be unfounded, or based primarily on marketing hype. UUCP: {amdahl!bungia, uunet!rosevax, chinet, killer}!orbit!pnet51!elec ARPA: crash!orbit!pnet51!elec@nosc.mil INET: elec@pnet51.cts.com ------------------------------ Date: Mon, 22 Jan 90 16:11:44 PST From: Don Craig Subject: Re: Risks of supermarket checkout scanners David Marks quotes an INSIGHT magazine article: "Retailers contend that just as many pricing errors are made in favor of the customer..." What then should the attentive shopper, checking his prices, do when he sees an UNDERcharge go past? My conscience is regularly stricken when I shop at the local purveyor of organic and transitional organic foodstuffs. Service ranges from pleasant and ineffectual through bossy and dumb, checkout pricing is by seminumerate human being. I buy Thomas Hardy's ale there, which costs $2.89 for a 6 ounce bottle, or $11.56 for a carton of 4. Each bottle is marked $2.89, but the carton price appears nowhere. If asked by the checkout clerk I tell them the price is $11.56, but if they don't ask I accept what they charge. About half the time, it's $2.89 for the whole carton. I tell myself this makes up for the utter incompetence of say, the organic meat department, but I still feel guilty when I leave. What should I do? ...Distressed in Oregon [Perhaps it is really Oregonic meat, not Organic meat, and someone is illiterate as well as innumerate. Perhaps you should switch to Samuel Adams beer. Although Hardy was more literate, Adams might have been more patriotic. But you could have a nice chat with the manager. You will probably find that the hearty ale is not Bar Coded. (HardyHar at your neighborhood bar.) PGN] ------------------------------ Date: Tue, 23 Jan 90 9:52:55 EST From: "Michael J. Chinni, SMCAR-CCS-E" Subject: Robert T. Morris Convicted The following is an excerpt from a message sent by one of our computer security people. Michael J. Chinni, Picatinny Arsenal, New Jersey Verdict: "GUILTY" Student "worm" whiz is found guilty. A U.S. court jury returned its verdict about 9:30 pm after approximately six hours of deliberation. Robert T. Morris was found guilty of federal computer tampering charges for unleashing a rogue program that crippled a nationwide computer network (Internet system). A date for sentencing has not yet been set. Morris faces up to five years in prison and a $250,000 fine. He is the first person brought to trial under a 1986 federal computer fraud and abuse law that makes it a felony to break into a federal computer network and prevent authorized use of the system. Morris testified that he had made a programming error that caused a computer "worm" to go berserk and cripple the Internet system back on November 2, 1988. The "worm" he designed immobilized an estimated 6,000 computers linked to Internet, including ones at the NASA, some military facilities and a few major universities. Morris's attorney Thomas Guidoboni argued that Morris never intended to prevent authorized access. However testimony showed Morris did indeed deliberately steal computer passwords from hundreds of people so the "worm" could break into as many computers as possible. It was brought out in the trial that he took deliberate and conscious steps to make the rogue program difficult to detect and eliminate. Morris camouflaged sending of the program by unleashing it from the computer system at Massachusetts Institute of Technology in Cambridge and made it look like it had been sent from the University of California at Berkeley so authorship of the program could not be traced to him at Cornell. Other evidences showed Morris had at least six earlier versions of the "worm", which had been found on his Cornell computer accounts and that his own comments on the "worm" program used the words "break-in" and "steal". ------------------------------ Date: Mon, 15 Jan 90 10:34:30 PST From: cooper@sm.unisys.com (Debbie Cooper) Subject: Advance Program for Oakland Symposium (REVISED, 9 Jan 90) 1990 IEEE Symposium on Research in Security and Privacy ADVANCE PROGRAM (Proceedings later from IEEE) Monday, May 7, 1990 Praxis I, Steve Lipner, Chair Status Update, Steve Lipner A VMM Security Kernel for the VAX Architecture, Paul Karger, Mary Ellen Zurko, Douglas W. Bonin, Andrew H. Mason An Architecture for Practical Delegation in a Distributed System, Morrie Gasser, Ellen McDermott Practical Authentication for Distributed Computing, John Linn SP3 Peer Entity Identification, Bill Birnbaum Praxis II, Elizabeth Sullivan, Chair The Army Secure Operating System, Neil Waldhart Specification and Verification of the ASOS Kernel, Ben L. Di Vito, Paul H. Palmquist, Eric R. Anderson, Michael L. Johnston Database I, Teresa Lunt, Chair Integrating an Object-Oriented Data Model with Multilevel Security, Sushil Jajodia, Boris Kogan A Little Knowledge Goes a Long Way: Fast Detection of Compromised Data in 2-D Tables, Dan Gusfield Extending the Brewer-Nash Model to a Multilevel Context, Catherine Meadows Database II, Earl Boebert, Chair Polyinstantiation and Integrity in Multilevel Relations, Sushil Jajodia, Ravi Sandhu Naming and Grouping Privileges to Simplify Security Management in Large Databases, Robert W. Baldwin Referential Secrecy, Rae K. Burns Tuesday, May 8, 1990 Information Flow, John Rushby, Chair Information Flow in Nondeterministic Systems, J. Todd Wittbold, Dale M. Johnson Constructively Using Noninterference to Analyze Systems, Todd Fine Probabilistic Interference, James W. Gray, III Security Models and Information Flow, John McLean Access Control and Integrity, Roger Schell, Chair Beyond the Pale of MAC and DAC -- Defining New Forms of Access Control, Catherine Jensen McCollum, Judith R. Messing, LouAnna Notargiacomo Some Conundrums Concerning Separation of Duty, Michael J. Nash, Keith R. Poland Authentication, Tom Berson, Chair The Role of Trust in Protected Mail, Martha Branstad, W. Curtis Barker, Pamela Cochrane On the Formal Specification and Verification of a Multiparty Session Protocol, Pau-Chen Cheng, Virgil D. Gligor Reasoning about Belief in Crytographic Protocols, Li Gong, Roger Needham, Raphael Yahalom A Security Architecture and Mechanism for Data Confidentiality in TCP/IP Protocols, Raju Ramaswamy Auditing and Intrusion Detection, Jim Anderson, Chair The Auditing Facility for a VMM Security Kernel, Kenneth F. Seiden, Jeffrey P. Melanson Adaptive Real-time Anomaly Detection Using Inductively Generated Sequential Patterns, Henry S. Teng, Kaihu Chen, Stephen C-Y Lu Auditing the Use of Covert Storage Channels in Secure Systems, Shiuh-Pyng Shieh, Virgil D. Gligor Wednesday, May 9, 1990 Verification, Deborah Cooper, Chair The Deductive Theory Manager: A Knowledge Based System for Formal Verification, Ben Di Vito, Cristi Garvey, Davis Kwong, Alex Murray, Jane Solomon, AmyWu Formal Construction of Provably Secure Systems with Cartesiana, Heinz Brix, Albert Dietl Verifying A Hardware Security Architecture, Joshua D. Guttman, Hai-Ping Ko A Hierarchical Methodology for Verifying Microprogrammed Microprocessors, Phillip Windley Database III, Cristi Garvey, Chair Transaction Processing in Multilevel-Secure Databases Using Replicated Architecture, Sushil Jajodia, Boris Kogan Multiversion Concurrency Control for Multilevel Secure Database Systems, T.F. Keefe, W.T. Tsai Modeling Security-Relevant Data Semantics, Gary W. Smith Covert Channels Panel, Marv Schaefer, Chair A1 With a Twist: Can a Fast Machine Be Secured? Post-Symposium Panel Session, Carl Landwehr, Chair International Orange II: A Spectrum of Computer Security Criteria ------------------------------ End of RISKS-FORUM Digest 9.62 ************************