Subject: RISKS DIGEST 15.20 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 1 November 1993 Volume 15 : Issue 20 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Breakdown in computerised voter support, Oslo (Reidar Conradi) Norwegian hackers fined (\ystein Gulbrandsen) White House distributes STONED 3 virus (Andrew Klossner) Police feedback (Graeme Jones) Taurus Project (E. Kelly) Magnetic Fields in Subway Cars (Bob Drzyzgula) Report on Software Product Liability (Charles Youman) Re: Dangers of Fibre Optic cable (John Gray) Re: CERT Reports and system breakins (Mike Raffety) Re: CERT (was "security incident handling") (A. Padgett Peterson) Re: Ethernet addresses as "port" ids (A. Padgett Peterson) 3rd SEI Conference on Software Risk, 5-7 April 1994, Pittsburgh (Ellen Ayoob) Workshop on IT Assurance and Trustworthiness (Marshall D. Abrams) ISOC Symposium on Network and Distributed System Security (Danny Nessett) The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. There are also alternative repositories, such as bitftp@pucc.Princeton.EDU . If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Mon, 1 Nov 1993 23:33:25 +0100 From: Reidar.Conradi@idt.unit.no Subject: Breakdown in computerised voter support, Oslo Computer error in parliamentary election, Oslo., 13 Sept. 1993 The parliamentary election in Oslo on Monday 13 Sept. 1993 attempted to use a new, computerised system for electorate management ("manntallskontroll" in Norwegian). The system should keep track of electorate composition and participation -- but not what was voted for. By this system, the city hoped to reduce the number of employees from 3000 to 1500 on election day, and planned for that. The electorate management system was developed since 1988 by the government's computing center (SDS) on a Bull mainframe connected to local PCs. The software had been tried out successfully in smaller elections both in Norway and Denmark, but had not been exposed to a full scale test. It is still unclear who was responsible for this lack of realistic testing -- the city of Oslo or SDS. However, the electoral management system developed severe "breathing" problems only 1/2 hour after election started at 09:00 on 13 Sept. 1993. It must be said to have effectively broken down, caused by a programming error in the local communication controllers, using character-based instead of line-based transmission protocols. The error was fixed at 14:00 on election day, but then the municipal election board had already decided to revert to manual backup procedures. These worked reasonably well, all factors considered. In fact, a group of specially invited, international observers from more "low-tech" countries was very impressed by the city's ability for manual improvisation. However, in the ensuing chaos, there were some irregularities, and 1200 votes had eventually to be discarded or were lost. Therefore, the municipal election board in Oslo unanimously decided to recommend a reelection 2-3 months later. This recommendation was turned down by the newly elected parliament during its own constitution -- in a 119 against 27 vote on 8 Oct. 1993. The reasoning was that the acknowledged election irregularities in Oslo were judged to be insignificant for both the municipal and national election outcomes. On the other hand, a reelection would very likely have caused changes among the elected deputies. Digression: The ballots were counted optically, *after* all the votes had been cast. The ballots had uniquely punched holes along the paper borders, resembling a punched card. The associated computerised system (also from SDS) worked without problems. However, the right for constituencies (counties) to use entirely electronic voting is still awaiting parliamentary approval ... ------------------------------ Date: Fri, 29 Oct 93 16:45:23 -0100 From: oysteing@taskon.no Subject: Norwegian hackers fined In Baerum (a small, wealthy area just outside Oslo, the capital of Norway), two hackers were accused of stealing telephone services, and several other forms of fraud. The elder (23) got 18 days suspended and a 2000NKR (300$) fine after last year having used a phony name and signed out a modem, and assorted computer-related items from a transport-company. He told the court that he was acting on behalf of another person he got in touch with on a BBS. He was told to check a mailbox (a physical one), and pick up the papers for transport there. He did so, and met with the transport company, identified himself mainly by the acquired papers, and signed out the goods. He paid with a stolen Eurocard-number. He left some of the aquired items on a public place, to be picked up by the other person involved, and kept some for himself. In court it also came out that he used to work at a gas-station, wrote down all credit-card numbers used, and mailed them around the world. The younger (16) had committed the same scam with the transport-company a couple of times for a "Calvin", which he met on a French BBS. He was fined 2000 NKR (300$). None of the boys were sentenced for telecom fraud, on technicalities. The court also found that the boys had been roaming international databases, but did not consider this a computer crime, as they had not destroyed or modified anything. (I personally would like to see a burglar getting of the hook because he did not find anything worth stealing!) The defendants and their lawyers were very satisfied with the verdict. \ystein Gulbrandsen Taskon A/S ------------------------------ Date: Fri, 29 Oct 93 10:23:19 PDT From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: White House distributes STONED 3 virus Heard on the Rush Limbaugh radio show of 10/29/93, not confirmed: The White House distributed the 1300-page health care legislation proposal widely on floppy disk. Copies went to legislative staffs and to the press. It seems that each disk was infected with the STONED 3 virus, which causes a PC to display "Your PC is STONED. Legalize marijuana." The commentator drew the obvious ironies and puns. (No doubt our esteemed moderator will find non-obvious puns.) -=- Andrew Klossner (andrew@frip.wv.tek.com) [People who live in grass browses shouldn't know STONED? PGN] ------------------------------ Date: Mon, 01 Nov 93 13:27:18 From: JONES_GE_3@prime1.central-lancashire.ac.uk Subject: Police feedback With the CERT-induced issue of passing sensitive information on to those that could really do with it in mind - I wondered if the British police have an official policy to hand over *all* such information to manufacturers of technical products with exploitable weaknesses. I have been told (don't quote me though!) that for instance, although forged banknote detectors are in use in even our local 20ft by 20ft store, the notes can simply be sprayed with hairspray (one brand works particularly well!) to bypass the ultraviolet light. Similarly, the so-called high security coded car stereos touted at a premium because thieves can't use them can apparently just be placed in the freezer for a while... Makes me wonder what else clever(?) thieves could achieve if put in charge of a DTI department to boost our exports by undermining foreign products!! Only joking - I've just watched "Rising Sun"... Graeme ------------------------------ Date: Mon, 1 Nov 93 15:17 GMT From: EKELLY@dit.ie Subject: Taurus Project In the October 1993 issue of the CACM Inside Risks column, I was surprised that there was no mention of the London Stock Exchange Taurus project which was abandoned in March 1993 after a total expenditure of #400 million pounds sterling (about US$ 600 million). The British journal "Computing" carried several articles on it. The principle function of the Taurus project, as far as I know, was to computerize the share certificate settlement system. ------------------------------ Date: Fri, 22 Oct 93 12:47:44 -0400 From: Bob Drzyzgula Subject: Magnetic Fields in Subway Cars Commuting on the Washington, D.C. Red Line this morning, I noticed, out of the corner of my eye, something on the floor flash. As I looked closer, I understood that what I saw was a paper clip. But I could have sworn that it moved. A minute later, it did. It stood up on end, about 60 degrees from the plane of the floor. It did this for about 5 seconds, and then fell to the floor again. I watched this go on for about a half an hour... every time the train would accelerate or decelerate, the paper clip would stand up at a rigid 60 degree angle until the train operator disengaged the (electric) drive motors. It probably did this 50 times during my trip. Given that I had some floppy disks in my pack, it made me kind of nervous. And knowing that I have many times, under more crowded circumstances, stood just where that paper clip was (almost exactly in the center of the rail car's floor) with my pack on resting on the floor, I was kind of dismayed. And here I always blamed the cheap floppies my office buys. So I guess... well, you've been warned. Bob Drzyzgula rcd@frb.gov ------------------------------ Date: Sat, 30 Oct 93 21:50:03 -0400 From: youman@umiacs.UMD.EDU (Charles Youman) Subject: Report on Software Product Liability I ran across a report that may be of interest to RISKS readers. It is a SEI report: Software Product Liability (CMU/SEI-93-TR-13) by Jody Armour (School of Law, U. of Pittsburgh) and Watts S. Humphrey (SEI Fellow, Software Engineering Institute). It is available (Postscript, but without figures) via anonymous FTP from ftp.sei.cmu.edu in directory pub/documents/93.reports as file tr13.93.ps. The abstract starts with a reference to an accident involving a radiation machine [Therac 25], although it is not specifically identified, is likely to be an accident already extensively discussed in RISKS, so I have omitted it. The rest of the abstract follows: Software defects are rarely lethal and the number of injuries and deaths is now very small. Software, however, is now the principle controlling element in many industrial and consumer products. It is so pervasive that it is found in just about every product that is labeled "electronic." Most companies are in the software business whether they know it or not. The question is whether their products could potentially cause damage and what their exposures would be if they did. While most executives are now concerned about product liability, software introduces a new dimension. Software, particularly poor quality software, can cause products to do strange and even terrifying things. Software bugs are erroneous instructions and, when computers encounter them, they do precisely what the defects instruct. An error could cause a 0 to be read as a 1, an up control to be shut down, or, as with the radiation machine, a shield to be removed instead of inserted. A software error could mean life or death. ------------------------------ Date: Thu, 28 Oct 93 12:48:02 GMT From: John Gray Subject: Re: Dangers of Fibre Optic cable (Kenny, RISKS-15-19) Robin Kenny mentions the danger of handling optical fibre in RISKS-15.19. I can believe the telecom worker story, but that probably arose from careless handling. "Raw" optical fibre is too brittle for practical use (partly because a fragment snapped from it would be dangerous) so *all* fibres are coated in a flexible plastic coating before they are put onto drums. Thus, what the people were handling is perfectly safe (you need to bend a fibre very tightly before it snaps). Providing the ends of the fibre are not exposed it is safe to handle. In order to splice fibre ends, you have to strip off the plastic coating, and then any pieces of fibre core which are cut off must be disposed of safely. I suspect that the Telecom worker concerned was working with the bare, uncoated fibre which is brittle and dangerous. Possibly the risk of connecting unrelated scenarios? I wouldn't stop children from changing channel on a TV just because a TV service engineer had been electrocuted while servicing one.... John Gray ------------------------------ Date: Thu, 28 Oct 93 12:44:05 CDT From: Mike Raffety Subject: Re: CERT Reports and system breakins (Peterson, RISKS-15.17) > It would be very difficult (well, nothing is impossible but this > would be close) for software to forge an address using commercial > equipment and collisions should be obvious. Sorry, it's trivial; every Sun workstation can change its Ethernet address (see the ifconfig command). And in fact, any computer that can do DECnet must be able to do this, since DECnet requires a direct relationship between the Ethernet address and the DECnet address (dumb, but true). > Given this number and a database to correlate the ethernet address to a > particular system/location, it is possible to identify not only the user > with conventional means, but also determine whether the access is from a > known terminal. Sorry, this isn't useful in real life. The Ethernet address will not cross routers; this "solution" would only be useful if both ends of the data flow are on the same network segment (possibly bridged, but not routed). ------------------------------ Date: Thu, 28 Oct 93 09:06:20 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: CERT (was "security incident handling") (Moran, RISKS-15.19) I am not connected with CERT (other than knowing a number of the people involved) and can understand Mr. Moran's position. It is true that generally CERT is "input only" and, while I do not necessarily agree with their position, it is arguable. CERT does not and cannot provide solutions, they are not funded to do so. It is also their policy not to discuss reported problems other than with the developer of the product in question, and only to produce advisories when a fix for the problem is available. Having tried to convince manufacturers before that there is a problem, IMHO CERT plays a very necessary role in this matter since CERT does not have to establish credentials. I do have an advantage over CERT in that, as a hobbyist, I can create and distribute a "fix" with no guarantees or warranties, something neither CERT nor the manufacturer can do (one of the problems with a litigation-happy society). Of course since the "bad guys" enjoy this freedom also, it is a difficult matter. I can state uncategorically that it is *much* more difficult to write an anti-virus program than a virus, much easier to hack/crack than to protect in a manner inoffensive to legitimate users, but then I am egotistical enough to accept those handicaps. Back to the subject at hand, for example there is currently what I consider a severe problem in Novell Netware 3.x and 4.x that will not be discussed openly just yet since there is no fix. Novell has been contacted and hopefully a new "feature" will soon appear - for Novell the fix should just require a simple change to a single program (maybe 2). My advantage is that for me this is an ethical choice and not a policy or business dictate, a freedom which neither CERT nor the vendor enjoys. I do know that many people within such organizations do not necessarily agree with such decisions but have no choice in the matter. Thus I do feel that CERT plays a very valuable role in the process of computer security though it is not often visible as such. Padgett ------------------------------ Date: Thu, 28 Oct 93 09:33:06 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Ethernet addresses as "port" ids (Bob Rahe, RISKS-15.19) >From: bob@hobbes.dtcc.edu (Bob Rahe) > Unfortunately, there are two problems here. The first is probably the >most damaging - the ethernet address is the address of the transmitting unit >ON THAT ETHERNET segment. If the unit is not on that segment and is sending >via a router, for example, then the ethernet address will be that of the >router's ethernet transmitter, and not the originator's physical address. While Mr. Rahe is correct as far as a PING is concerned, the actual packets *must* contain the actual hardware address of the sender in order for the host/server to respond. The fact that the real address may be buried a bit in the packet does not mean that it is not there. Further, the little .COM program I mentioned runs on the client itself, routing has nothing to do with it, and was designed to be run as part of a login script. My concept was simple: if all "approved" addresses are known, unapproved addresses are easy to spot. Further, even using the PING method, if I have (and most do) just one or two bridges/routers leaving my reservation then *anything* with their address header should be subject to closer scrutiny. The problem here is not a matter of too little data but too much (as anyone who has ever used an unfiltered "sniffer" knows). What I am suggesting is a means of reducing that data to manageable proportions. Padgett ------------------------------ Date: Mon, 01 Nov 93 15:04:53 EST From: Ellen Ayoob Subject: 3rd SEI Conference on Software Risk, 5-7 April, 1994, Pittsburgh, PA Sponsor: Software Engineering Institute Contact: Julie Walker, SEI, Carnegie Mellon University, Pittsburgh, PA 15213-3890 phone (412)268-5051 FAX (412)268-5758 e-mail jaw@sei.cmu.edu Theme: Risk Management in Practice Please call me if you have any questions or need more information. Ellen M. Ayoob, (412) 268-6932 ------------------------------ Date: Mon, 01 Nov 93 16:21:46 EST From: (Marshall D. Abrams) Subject: Workshop on IT Assurance and Trustworthiness ******* REQUEST FOR PARTICIPATION ******* Invitational Workshop on Information Technology (IT) Assurance and Trustworthiness March 21-23, 1994 Williamsburg, Virginia Sponsored by: Aerospace Computer Security Associates Co-sponsored by National Computer Systems Laboratory, National Institute of Standards and Technology The purpose of this workshop is to provide input into the development of policy guidance on determining the type and level of assurance appropriate in a given environment. Much of the existing guidance is rooted in the Yellow books, which are based on computer and communications architectures of a prior decade. Technological changes such as local area networks, the worldwide Internet, policy-enforcing applications, and public key cryptography, mandate a review and revision of policy guidance on assurance and trustworthiness. This invitational workshop is intended to identify the crucial issues and to make recommendations. The audience for the results includes those who deal with information having sensitivity with respect to national security, privacy, commercial value, integrity, and availability. Potential participants will submit a paper expressing a technical or policy position. These position papers will be used to identify working sessions and to help identify specific participants who should be invited. The submission of the papers and all communication surrounding this workshop will be handled primarily through electronic means. [...] If you are interested in submitting a paper or just want additional information, please contact Marshall Abrams, abrams@mitre.org. ------------------------------ Date: Mon, 1 Nov 93 09:50:01 PST From: nessett@ocfmail.ocf.llnl.gov (Danny Nessett) Subject: ISOC Symposium on Network and Distributed System Security Thursday, February 3 [Breaks etc. removed by PGN] 8:30 A.M. Opening Remarks 9:00 A.M. Session 1: Electronic Mail Security, Chair: Steve Kent (BBN) Certified Electronic Mail, Alireza Bahreman (Bellcore) and Doug Tygar (Carnegie Mellon University), USA Privacy Enhanced Mail Modules for ELM, Selwyn Russell and Peter Craig, Queensland University of Technology, Australia Management of PEM Public Key Certificates Using X.500 Directory Service: Some Problems and Solutions, Terry Cheung, Lawrence Livermore National Laboratory, USA 11:00 A.M. Session 2: Panel: Public Key Infrastructure, Santosh Chokhani (MITRE), Michael Roe (Cambridge University), Richard Ankney (Fischer, Intl.) Chair: Miles Smid (NIST) 2:00 P.M. Session 3: Protocols, Chair: Tom Berson (Anagram Labs) Paving the Road to Network Security, or The Value of Small Cobblestones, H. Orman, S. O'Malley, R. Schroeppel, and D. Schwartz, University of Arizona, USA A Complete Secure Transport Service in the Internet, Francisco Jordan and Manuel Medina, Polytechnical University of Catalunya, Spain 3:30 P.M. Session 4: Internet Firewall Design and Implementation Chair: Jim Ellis (CERT) Inter-LAN Security and Trusted Routers, Pal Hoff, Norwegian Telecom Research, Norway Trusted to Untrusted Network Connectivity: Motorola Authenticatd Internet Access -- MANIAC(TM), Bill Wied, Motorola, USA BAfirewall: A Modern Firewall Design, Ravi Ganesan, Bell Atlantic, USA WhiteHouse.Gov: Secure External Access and Service for the Executive Office of the President, Frederick Avolio and Marcus Ranum, Trusted Information Systems, USA 7:00 P.M. Banquet Friday, February 4 8:30 A.M. Session 5: Panel: All Along the Watchtower: Experiences and Firefights Managing Internet Firewalls, Brian Boyle (Exxon Research), Brent Chapman (Great Circle Consulting), Bill Cheswick (AT&T Bell Labs), Allen Leibowitz (Warner-Lambert), Marcus Ranum (TIS) Chair: Frederick Avolio (TIS) 10:30 A.M. Session 6: Issues in Distributed System Security Chair: Cliff Neuman (USC-ISI) CA-Browsing System -- A Supporting Application for Global Security Services, Denis Trcek, Tomas Klobucar, Borka Jerman-Blazic, and Franc Bracun, Jozef Stefan Institute, Slovenia The X.509 Extended File System, Robert Smart, CSIRO Division of Information Technology, Australia Auditing in Distributed Systems, Shyh-Wei Luan (VDG, Inc.) and Robert Weisz (IBM Canada Laboratory), USA/Canada 1:30 P.M. Session 7: Authentication, Chair: Dave Balenson (TIS) The S/KEY(tm) One-Time Password System, Neil Haller, Bellcore, USA A Technique for Remote Authentication, William Wulf, Alec Yasinsac, Katie Oliver, and Ramesh Peri, University of Virginia, USA Remote Kerberos Authentication for Distributed File Systems: As Applied to a DCE DFS-to-NFS File System Translator, Thomas Mistretta and William Sommerfeld, Hewlett-Packard, USA 3:30 P.M. Session 8: Panel: IP Security Alternatives, K. Robert Glenn (NIST), Paul Lambert (Motorola), David Solo (BBN), James Zmuda (Hughes) Chair: Russell Housley (Xerox) PROGRAM CO-CHAIRS Russell Housley, Xerox Special Information Systems Robert Shirey, The MITRE Corporation GENERAL CHAIR, Dan Nessett, Lawrence Livermore National Laboratory PROGRAM COMMITTEE Dave Balenson, Trusted Information Systems Tom Berson, Anagram Laboratories Matt Bishop, University of California, Davis Ed Cain, U.S. Defense Information Systems Agency Jim Ellis, CERT Coordination Center Steve Kent, Bolt, Beranek and Newman John Linn, Geer Zolot Associates Clifford Neuman, Information Sciences Institute Michael Roe, Cambridge University Robert Rosenthal, U.S. National Institute of Standards and Technology Ravi Sandhu, George Mason University Jeff Schiller, Massachusetts Institute of Technology Peter Yee, U.S. National Aeronautics and Space Administration Contact nessett@ocfmail.ocf.llnl.gov (Danny Nessett) for registration and other information, or write ISOC Symposium, C/O Belinda Gish, L-68, Lawrence Livermore National Laboratory, Livermore, CA. 94550. ------------------------------ End of RISKS-FORUM Digest 15.20 ************************