Subject: RISKS DIGEST 12.29 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 10 September 1991 Volume 12 : Issue 29 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: CIA dumps on the National Security Archive (Tom Slone) CAA grant Cat IIIB autoland clearance for 747/767 (Martyn Thomas) Follow-up on Hobson's M16 story (Jim Purtilo) Risks of Incompatibilities (Harry Erwin) Crackers for hire (Mark Seecof) Re: Salomon Brothers -- Database Design (Dan Drake) Re: Risk assessment: a specific experience (Peter Wayner) Re: The risk of thinking we are in control (Larry Seiler) Re: National characters on car plates (Torsten Lif) Re: Failsafe mode for 3.5" Floppies (BartMassey, BruceHamilton, AndrewKlossner) Re: Number of virus events dropping (Mark Hittinger) Re: Prize for Most Useful Computer Virus (Raymond Chen, Richard A. Schumacher, Dave Butterfield) It is RISKy to believe that Averages are `average' [!] (David Paschall-Zimbel) Seventh Annual Conference on Computer Assurance (James Bret Michael) 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. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, 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. 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, 9 Sep 91 18:43:50 PDT From: potency@violet.berkeley.edu (Tom Slone) Subject: CIA dumps on the National Security Archive The National Security Archive (NSA), a non-profit clearinghouse for Freedom of Information Act (FOIA) materials, requested from the Central Intelligence Agency (CIA) a list of materials that the CIA had released under the FOIA. The CIA responded to the request by producing "a random dump", 5000-pages long summarizing the released material. The NSA and the CIA are frequently at odds with each other, hence the "hostile" reply by the CIA. Under the FOIA, agencies are not required to create (i.e. organize, sort, or merge) data, merely to provide information that already exists. So, it is unlikely that the NSA would have any recourse other than to attempt to reconstruct the index from the info-garbage it was given. [Common Cause 17(4): 20 (1991)] ------------------------------ Date: Tue, 10 Sep 91 12:02:06 BST From: Martyn Thomas Subject: CAA grant Cat IIIB autoland clearance for 747/767 Flight International (11 Sept 1991) reports that British Airways has been granted Category IIIB autoland clearance for its 747-400s and 767s by the UK CAA. Cat IIIB means that autolandings are permitted where the decision height is touchdown (zero altitude cloud ceilings) and the forward visibility is zero. BA are requiring 100 metres visibility for the 747 to taxi (75m for the 767). The clearance was granted after the CAA has monitored "almost flawless" autoland trials. 440 approaches were demonstrated on the 747, 520 on the 767. "At the heart of the system in both types is the Collins FCC132 flight control computer". The 747 clearance includes 3-engine operation. The single-engine limits for the 767 are 14m decision height and 200m visibility. BA expects FAA clearance for Cat IIIB in about six months. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk ------------------------------ Date: Mon, 9 Sep 91 18:58:27 -0400 From: purtilo@cs.UMD.EDU (Jim Purtilo) Subject: follow-up on Hobson's M16 story (RISKS-12.28) John Hobson gives a nice summary of the risks associated with rushing a weapons system into use either prematurely or after lots of modifications are mandated by paper-pushers. He makes passing reference to the greater-than-usual need for cleaning of the firearm in its second major ... umm ... "distribution" (the M16A1). The detailed story behind that is itself a study in mismatched specifications. The cartridge ultimately chosen for the M16 was originally a ``wildcat'' round, and to some extent it evolved with the light rifle designs (some of which are referred to as the Stoner system, although Eugene Stoner's ideas affected to several products of the era ... the designs were successively owned by several companies during early 60's.) One of the goals for this combination of rifle and cartridge --- as inspired by those nice folks at DARPA, I believe --- was to have a system that we average users would not have to waste time cleaning at all. The system as rapidly tested and then fielded achieved this goal. Then government procurement got into the act. When the contracts for large quantities of ammunition were written, the part of the specification about not needing to clean the rifle was violated: to serve manufacturing needs, companies used a slightly different formula for the powder than was used in the original cartridge. Its use resulted in much greater accumulation of residue in the rifle's gas system, in turn increasing failure rates (often with consequences that didn't have as happy an ending as Hobson's story). The whole mess was made worse since everyone was told *not* to clean the rifle, and no cleaning kits were shipped with the first rifles delivered. Before the problem was sorted out, congress got involved and the reputation of an otherwise serviceable system was permanently damaged. For what it's worth, those of us who actively compete in this class of shooting sports use the M14, which led off Hobson's article. I guess we either view the committee-designed tweaks to the Garand design as "features" or we have longer arms than he does. Jim ------------------------------ Date: 9 Sep 91 12:30:01 GMT From: trwacs!erwin@uunet.uu.net (Harry Erwin) Subject: Risks of Incompatibilities I'm interested in identified incompatibilities between the various US Government standards, beginning with POSIX GOSIP Ada B2 Security (etc.) in various applications. I know of one between UNIX-based POSIX implementations and Ada tasking that makes the combination inappropriate in safety-critical real-time and near-real-time applications, and I'm interested in identifying any others that are known for specific applications. [NOTE ADDED LATER IN REPONSE TO A QUERY FROM PGN:] There is a real issue. Ada running over UNIX can't handle data enablements of tasks reliably--the problem being that you don't have access to a test-and-set instruction and you can be interrupted in the middle by the arrival of data from outside. The result is spurious enablements and the loss of other enablements. That can be disastrous in a safety- or nuclear- critical system. How many nuclear-capable systems have been written using Ada tasking over UNIX? How many other problems have been created by incompatible standards? If you want a background brief, call me at (W)703.734.6092 or (H)703.758.9660. Harry Erwin Internet: erwin@trwacs.fp.trw.com ------------------------------ Date: Tue, 10 Sep 91 10:50:05 -0700 From: Mark Seecof Subject: Crackers for hire In the September 19th Rolling Stone at page 67 an article titled "Samurai Hackers" by Lynda Edwards tells us that a: "new breed of hacker has been finding a niche in the corporate world in the last two years. These hackers are hired by white-collar professionals at ad agencies, law firms, newspapers, and investment houses who want to steal co-workers' ideas and clients or pillage supervisors computer files for marketing strategies, performance evaluations and managerial gossip." Ms. Edwards presents several tales of crackers hired by unethical people in business to snoop in or sabotage other peoples' computer files. She also describes how victims sometimes hire their own crackers to mount a counter-attack. The crackers use their knowledge and skills to ferret out information from companies' networks and minicomputers. They usually receive a leg up from their employers, who get them modem 'phone numbers and basic account/password info. The crackers then overcome or bypass the often trivial security on the target systems. Most of what they do could be done by any jackleg expert with a given system, but the crackers are the agents of computer illiterates and thus constitute a threat unconsidered by the managers of systems in non-computer businesses. These crackers are seen to be somewhat akin to the wandering samurai of Japan's past. They work as mercenaries, honing their own skills and testing them in combat on behalf of employers they often hold in contempt. (The crackers are said to refer to ignorant computer users as "Stupids.") The samurai image is distorted and romanticized but the jobs the crackers take on are very real. These crackers are well paid by those who hire them through bulletin boards or by word-of-mouth. Tales of their exploits circulate on BBS's and they are getting some notice in 2600 magazine. [Begin Mark S.'s comments.] Of course, the notion of the computer whiz employed by some nefarious scheming man or woman of business is not new. What is new is the increasing dependence of service businesses on networked PC's. In the past non-computer firms tended to rely on computers and software dedicated to certain business tasks like accounting, process control, engineering, printing paychecks. These were often vulnerable to cracking for one purpose or another, but they weren't much of a resource for "fuzzy" information like supervisors' memos or private e-mail. Even offices using word- processing systems often relied on stand-alone machines which were easy to crack if you had the office key but impossible to crack by 'phone or from another office because they were not connected to any communication links. Only recently have PC networks become all-purpose communication tools in places like law or advertising offices where you can find memos, workups, payroll info, private diaries, electronic mail, etc. all lurking in the system. All in all, this sort of thing seems to bolster the argument that systems should be designed with security features even if the end customer doesn't know to ask for them. A cracker given access to one employee's account should not be able to use that access as a springboard to crack all of the other accounts or data on the system. Mark Seecof Publishing Systems Dept. Los Angeles Times ------------------------------ Date: Tue, 10 Sep 91 09:43:39 PDT From: autodesk!gilroy!drake@fernwood.mpk.ca.us (Dan Drake) Subject: Re: Salomon Brothers -- Database Design (Dye, RISKS-12.28) >Bravo. The database programmers made a mistake. The Salomon traders >committed a crime. Not quite. The programmers implemented a design that was laid down in detail (you may assume, and hope) by analysts working under the direct orders of executives from Operations and Finance. It's the job of those gentlemen to ensure controls and audit trails. Their failure to do so is much more serious than an error by programmers: it is more evidence of incompetence and/or corruption, most likely both, pervading the company. Dan Drake drake@Autodesk.com ------------------------------ Date: Tue, 10 Sep 1991 13:37:05 GMT From: wayner@cs.cornell.edu (Peter Wayner) Subject: Re: Risk assessment: a specific experience. Mark Fulk's article on the fetal tests on pregnant women brought back memories of my younger days several years ago when I was in Yale Med School. Well, it was only for a day and I was visiting friends and they took me to one class which was on pre-natal diagnosis. I remember a very practical and straight-forward professor discussing all of the possible techniques for checking out the womb and making sure everything was okay. He would carefully explain the technique and all the facts you could discern from the various bits of bio-matter you could snag from the womb. The Maternal Serum Alfa-fetoprotein test is only the beginning of their bag of tricks. It turns out that the doctors can't learn too much from this one because the fluid comes from the mother and contains only a very dilute amount of the child's bio-matter. The next step up was to get some of the chorion (sp?) which is essentially the boundary layer between the placenta and the uterus. All the nutrients pass through this membrane so it is rich in data. The most aggressive procedure, though, was when they poked around with a needle until they managed to find the placenta. Then they grabbed a bit of fetal blood. This, the professor explained, was a data gold mine. The rub was inserted very parenthetically at the end of each section of the lecture. He would say things like, "the amniocentesis test is the most successful and we find we only induce miscarriages in 1 to 2% of the time." (All numbers in this section are subject to bad memory fudging. They are approximate.) I remember thinking to myself, "Wow! 99% that's great!" because I think I was lead on by the can-do tenor of the lecture. About 5 minutes later I realized that "inducing miscarriages" was not the same as failing to cure cancer or a cold. It was a big deal. Statistically it was a violation of the Hippocratic oath. The patient died because the doctor was curious. And as it was the only "cure" they have for Down's Syndrome or other tri-somic babies is abortion. The tone of the lecture, though, was much worse that the attitude that you couldn't make an omelette without breaking eggs. They didn't do any of the risk analysis or any number crunching what-so-ever. The lecturer just ploughed on and his manner and diction was just saying, "We're doctors. This is what we do." Peter Wayner Department of Computer Science Cornell Univ. Ithaca, NY 14850 EMail:wayner@cs.cornell.edu Office: 607-255-9202 or 255-1008 ------------------------------ Date: Tue, 10 Sep 91 12:35:50 PDT From: LARRY SEILER Subject: Re: The risk of thinking we are in control (Kerns, RISKS-12.24) Robert W. Kerns lists this point that makes people dislike certain risks: * Low amount of individual control over individual risk factors. This is a very important point but not quite accurate. It is *perceived* control or *perceived* lack of control that affects risk aversion, and it is the difference between perception and reality that injects a lot of the irrationality into most people's risk avoidance behavior (myself included). For a simple example, one of the effects of being drunk is thinking that one isn't -- hence many people at great risk of injuring themselves and others go ahead and drive anyway, because feel that they are in control. I think people's apparent preference for old familiar risks over new risks is in the same category -- familiarity breeding a false sense of control. But preferring risks where one has individual control is, indeed, rational, provided that one really has control, and doesn't just feel one has control. Larry ------------------------------ Date: Tue, 10 Sep 91 11:10:08 +0200 From: Torsten.Lif@eos.ericsson.se Subject: Re: National characters on car plates As has been said before, the Scandinavian alphabets contain letters "alien" to Anglophones. One such is often referred to in English as "A-ring". In Danish it is written "aa". You can get it on a SUN keyboard by hitting "A*". It has ISO8859-1 codes 0xc5 (upper case) and 0xe5 (lower). On a PC it has character codes 0x81 and 0x8c. Vehicles from the Finnish archipelago A*land all have numbers starting with "A*L", followed by some digits. Since they are part of Finland, they may use the "SF" identification marker when travelling abroad, but some prefer to underline their regional identity by using an "A*L" sticker. I wonder how French police computers are set up to handle all this. The possible permutations of confusing mistakes here are fascinating. Torsten Lif, Ericsson Telecom AB, EO/ETX/TX/ZD, S-126 25 STOCKHOLM, SWEDEN Phone: +46 8 719 4881 ------------------------------ Date: Mon, 9 Sep 91 16:53:26 PDT From: bart@cs.uoregon.edu (Bart Massey) Subject: Re: RISKS of floppette write-protect systems (Phillips, RISKS-12.28) > ... In the days of the 5 1/4" diskettes, the sensing was in the opposite way Worse than that, *both* senses of write protect existed! If I recall correctly, the 5.25" floppies sold by a certain major retail electronics outlet differed from those sold by a certain major mainframe and microcomputer manufacturer in this respect! I was working with both kinds of equipment at the time (sigh) and, if I remember right, trashed a diskette by getting confused by this at one point. > ... it seems to me that the position of the plastic tab in the open > position signifying "protected" is backwards from a fail-safe > point of view. If dust prohibits sensing the position, or the > detector/light source fails, the drive will incorrectly assume > that the disk should be writable. Ahh, but the chief failure mechanism for the 5.25" diskette write-protect system was for the little "sticker" which was commonly used to write protect/enable the diskette to fall off -- this failure should make the disk write-protected, no? :-) Probably the 3.5" diskette emulates the argument of the above paragraph, even though it is no longer valid. What it *should* do, IMHO, is have the whole slider open, and use 2 LED/sensor pairs to write-enable the disk, with the obvious state table. Of course this would add $5 or more to the disk drive cost, for a possibly rare failure mode... Bart Massey bart@cs.uoregon.edu ------------------------------ Date: Mon, 9 Sep 1991 19:19:46 PDT From: Bruce_Hamilton.LAX1B@xerox.com Subject: Re: Failsafe mode for 3.5" Floppies 5.25" floppies' copy-protect is a risk because it is backwards from every other magnetic medium I have ever encountered. The standard is: You insert something to permit writing and remove it to protect. This is true for: -9-track tape (write rings) -VHS video cassette -audio cassette -8" floppy -3.5" floppy How come 5.25" floppies are backwards? --Bruce 213/333-3538 ------------------------------ Date: Tue, 10 Sep 91 13:03:38 PDT From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: Failsafe mode for 3.5" Floppies "If dust prohibits sensing the position, or the detector/light source fails, the drive will incorrectly assume that the disk should be writable." The RISK of assuming a particular implementation. My Panasonic 3.5" floppy disk drive senses the tab position by attempting to insert a metal probe into the hole. A successful insertion means that the disk can be written. The likely failure modes would falsely indicate unsuccessful insertion, i.e., write prohibited. -=- Andrew Klossner (andrew@frip.wv.tek.com) (uunet!tektronix!frip.WV.TEK!andrew) ------------------------------ Date: Sun, 8 Sep 91 21:06:36 -0400 From: an288@cleveland.freenet.edu (Mark Hittinger) Subject: Re: Number of virus events dropping I noted a comment in Cliff Stoll's message that he had the perception that virus events and interest were kind of winding down. I just wanted to comment that, indeed, the messages-per-week posted on some of the local hacker bbs virus groups has been dropping off steadily for months. In one case the "group" was deleted to make room for something else! Humanity can only write so many payroll programs right? Most viruses seem to be re-hashes of existing ones. Perhaps the fun is deflating? The idea of a helpful virus is an interesting one. Perhaps one that would sense when your PC is locked up and warm-reboot? HA. I suppose that a helpful virus would really be called a commercial TSR? Mark Hittinger [answ.machine] (606)-272-2424 PO BOX 43358 Middletown, KY 40243 ------------------------------ Date: Sun, 8 Sep 91 18:48:15 PDT From: raymond@math.berkeley.edu (Raymond Chen) Subject: Re: Prize for Most Useful Computer Virus In Cliff Stoll retells Fred Cohen's article which describes how viruses and virus-like programs can be beneficial. >automated bill-collectors, where, "each bill collector virus is a >small program designed to collect one bill"; this program modifies >itself depending on the debtor's response. [...] maintenance >viruses which dispose of temporary files or hung programs. I fail to see how these programs are virus-like. The first is a self- modifying program, and the second is what might be called a daemon. Neither program is (or in the second example, needs to be) self-reproducing. The only example of a `beneficial virus' I can think of is the one that was released to fight another virus, namely the `Animals' program. The problem with viruses of either sort (in my unqualified opinion) is that once released, they are hard to exterminate. Another (more likely?) possibility is that I'm completely misunderstanding the brief excerpt from Dr. Cohen's article. ------------------------------ Date: Mon, 9 Sep 1991 17:56:02 GMT From: schumach@convex.com (Richard A. Schumacher) Subject: Re: Prize for Most Useful Computer Virus I wonder whether Dr. Cohen's bill collector virus included a provision for an audit trail, say by appending a record of every transaction to a database? His "The Sciences" article mentions no such device, and indeed boasts the lack of any large permanent database as an advantage. Feature or bug? ------------------------------ Date: Mon, 9 Sep 91 15:20:32 -0700 From: Dave Butterfield Subject: RE: Prize for Most Useful Computer Virus I don't know about the *most* useful, but one very useful virus would be a virus that identifies and destroys other viruses. I suppose it would have to be more virulent that the others. Whoever implements this, please don't forget to program in some appropriate self-destruct condition... (Maybe there should be an RFC to cover that topic.) Dave ------------------------------ Date: Tue, 10 Sep 91 12:52 CST From: David Paschall-Zimbel Subject: It is RISKy to believe that Averages are `average' desint!geoff@uunet.UU.NET (Geoff Kuenning) writes: "Remember that, by definition, 50% of the population is of below-average intelligence," [David goes on to shoot down this old war-horse... once again... I truncated the rest of his message, but would like to remind our contributors that it really helps if you are alert enough to avoid the mistakes that have already been kicked around in back issues. See Mark Seecof's note in RISKS-12.11 that included counterexamples from Tim Smith and Jeremy Grodberg... And thanks to those of you who are on your toes. PGN] ------------------------------ Date: Mon, 9 Sep 91 11:32:59 -0400 From: jmichael@gmuvax2.gmu.edu (James Bret Michael) Subject: Seventh Annual Conference on Computer Assurance CALL FOR PAPERS Seventh Annual Conference on Computer Assurance The Seventh Annual Conference on Computer Assurance (COMPASS), sponsored by the Institute of Electrical and Electronic Engineers and IEEE Aerospace and Electronic Systems Society, in cooperation with the British Computer Society, will be held at the National Institute for Standards and Technology in Gaithersburg, Maryland, USA, June 15-18, 1992. The purpose of this conference is to bridge the gap between emerging technology for computer assurance from research laboratories into industrial computer systems development. Papers may present original research on theoretical aspects and applications of technology to assured computing, or may be reports detailing experiments, evaluations, and open problems in the use of new technologies for computer assurance. Typical but not exclusive topics of interest include: * Models and modelling (process, mathematical, and requirements models) * Formal approaches (proofs of correspondence, formal specifications, and IV&V) * Experiences with assurance (illustrative examples from communications, energy, financial, medical, military, transportation, and other types of systems) PAPER SUBMISSION: Authors are requested to send five single-sided copies of their papers (not exceeding 7,500 words) to the program chair by January 10, 1992. If available, an electronic mail address for the contact author should be included. Papers submitted simultaneously to another conference with published proceedings are disqualified. Papers will be refereed by the Program Committee and will be returned with comments. Accepted papers will be published in the proceedings. IMPORTANT DATES: Papers due: January 10, 1992 Notification of acceptance: March 7, 1992 Camera-ready paper due: April 1, 1992 Conference: June 15-18, 1992 Additional information about the COMPASS '92 can be obtained from the General Chair. All inquiries concerning paper submissions should be addressed to the Program Chair. GENERAL CHAIR: PROGRAM CHAIR: Robert Ayers Dr. Edgar H. Sibley ARINC Research Corporation Department of Information and 2551 Riva Road Software Systems Engineering Annapolis, MD 21401 USA George Mason University voice: (301)266-4741 4400 University Drive fax: (301)266-4040 Fairfax, VA 22030-4444 USA (703)993-1640, or esibley@gmuvax.gmu.edu ------------------------------ End of RISKS-FORUM Digest 12.29 ************************