24-Sep-86 21:01:23-PDT,11348;000000000000 Mail-From: NEUMANN created at 24-Sep-86 20:59:13 Date: Wed 24 Sep 86 20:59:13-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS-3.65 DIGEST Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Wednesday, 25 September 1986 Volume 3 : Issue 65 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: UNIX and network security again (Andy Freeman) F-16 software (Wayne Throop) NYT feature article on SDI software (Hal Perkins) Autonomous widgets (Mike McLaughlin) Robottle Management Software? (PGN) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.) ---------------------------------------------------------------------- Date: Mon 22 Sep 86 17:09:27-PDT From: Andy Freeman Subject: UNIX and network security again To: preece%mycroft@GSWD-VMS.ARPA cc: RISKS%CSL.SRI.COM@CSNET-RELAY.ARPA preece%mycroft@gswd-vms.ARPA (Scott E. Preece) writes: If you can't trust the code running on another machine on your ethernet, then you can't believe that it is the machine it says it is, which violates the most basic principles of the NCSC model. That's why electronic signatures are a good thing. I wrote (andy@sushi): > Then NCSC certification means nothing in many (most?) situations. Well, most sites are required to have certified systems (yet?). If they were, they wouldn't be allowed to have non-complying systems. The designers of the Ford Pinto were told by the US DOT to use $x as a cost-benefit tradeoff point for rear end collisions. Ford was still liable. I'd be surprised if NCSC certification protected a company from liability. (In other words, being right can be more important than complying.) [This case was cited again by Peter Browne (from old Ralph Nader materials?), at a Conference on Risk Analysis at NBS 15 September 1986: Ford estimated that the Pinto gas tank would take $11 each to fix in 400,000 cars, totalling $4.4M. They estimated 6 people might be killed as a result, at $400,000 each (the going rate for lawsuits at the time?), totalling $2.4M. PGN] Absolutely, network access should be as secure as phone access, IF YOU CHOOSE TO WORK IN THAT MODE. Our links to the outside world are as tightly restricted as our dialins. The Berkeley networking software is set up to support a much more integrated kind of network, where the network is treated as a single system. For our development environment that is much more effective. You should never allow that kind of access to a machine you don't control. Never. My interpretation of the original note was that the author's net contained machines with trusted-host access which should not have had such access; I contend that that represents NOT a failing of the software, but a failing of the administration of the network. My interpretation of Brian's original message is that he didn't have a choice; Berkeley network software trusts hosts on the local net. If that's true, then the administrators didn't have a chance to fail; the software's designers had done it for them. (I repeated all of Scott's paragraph because I agree with most of what he had to say.) -andy [I think the implications are clear. The network software is weak. Administrators are often unaware of the risks. Not all hosts are trustworthy. The world is full of exciting challenges for attackers. All sorts of unrealistic simplifying assumptions are generally made. Passwords are typically stored or transmitted in the clear and easily readable or obtained -- or else commonly known. Encryption is still vulnerable if the keys can be compromised (flawed key distribution, unprotected or subject to bribable couriers) or if the algorithm is weak. There are lots of equally devastating additional vulnerabilities waiting to be exercised, particularly in vanilla UNIX systems and networks thereof. Remember all of our previous discussions about not trying to put the blame in ONE PLACE. PGN] ------------------------------ Date: Tue, 23 Sep 86 19:12:33 edt From: rti-sel!dg_rtp!throopw%mcnc.csnet@CSNET-RELAY.ARPA Subject: F-16 software Apparently-To: mcnc!csl.sri.com!risks > I spoke to an F-16 flight instructor about this business concerning bomb > release when the plane is upside down. He said the software OUGHT to > prevent such an occurrence. When the plane is not at the right angle of > attack into the air stream, toss-bombing can result in the bomb being > thrown back into the airplane. Hmpf. *I* spoke to an ex Air-Force pilot. He said if *any* restriction on bomb release is incorporated it should be to prevent it when the plane (or more specificially, the bomb itself... there *is* a difference, and you had better realize it!) is pulling negative G's. This was my original point... "upside down" or "inverted" isn't the correct thing to worry about, it is the wrong mindset entirely, too simple a notion. He went on to back up this assertion by pointing out that there is a common (well... well-known anyhow) bombing technique, called "over the shoulder" bombing, that requires release while inverted. Consider the following diagram. (Note that the trajectory shapes are unrealistic and the scales are exagerated. Limitations of the terminal, don't y'know.) _ / \ / \ ________________________ | < / \r / \ | | v / B >___________________________________/ T Now, we have bomber B, release of bomb r, and target T. The bomber makes a fast, low-level run over the target (to avoid radar, and to let the bombsight get a good look). Then, soon after the overfly, pulls sharply up and over, and *while* *inverted* releases the bomb. The bomb lofts high into the air over the target whilst the plane scoots for home (rolling out of the inversion, presumably but not necessarily), and the bomb eventually lands splat on the target. Basically, if you want the flight computer to wet-nurse the pilot at all in this regard, it ought to have a sensor to detect strain on the bomb restraints, and refuse to release them if the bomb isn't currently "trying" to "fall" away from the aircraft. (Even this isn't foolproof, of course, but it comes close.) Tying this into the *attitude* of the *aircraft* *itself* is *WRONG* *WRONG* *WRONG*, and is, as I said before, an architypical computer risk, in that it is an overly simple and misleading model of the situation. The conversation I had with my friend makes a lot of sense to me, and the above somewhat vague stuff about the angle of attack does not. It could be I'm just missing something obvious, but I stand by my earlier position. The desire for safety stands against every great and noble enterprise. --- Tacitus ------------------------------ Date: Wed, 24 Sep 86 11:32:59 EDT From: hal@gvax.cs.cornell.edu (Hal Perkins) Subject: NYT feature article on SDI software To: risks@csl.sri.com The science section of last Tuesday's New York Times (16 Sept 1986) had a feature article on the SDI software problem starting on page C1. The headline is Software Seen As Obstacle In Developing 'Star Wars' Serious problems have forced dramatic changes in planning. by Philip M. Boffey The article is much too long to type in -- anyone interested can easily find a copy. The author has done his homework. He gives a good overview of the problems and of the issues in the SDI software debate and seems to have talked to the main people involved, several of whom are quoted. There's not much here that will be new to computer people who have been following the debate, but it's definitely worth reading. Hal Perkins, Cornell CS ------------------------------ Date: Wed, 24 Sep 86 10:32:29 edt From: mikemcl@nrl-csr (Mike McLaughlin) To: risks@csl Subject: Autonomous widgets The discussion of Autonomous Weapons should be expanded, considerably. Consider the following devices, soon to be found at your local dealer: Autonomous Lumberjack - locates and cuts down designated trees (pulp, hardwood, diseased... ) Autonomous Booter - identifies automobiles with more than n dollars in overdue tickets. Autonomous Streetsweeper - clears your street of any immobile object other than licensed vehicles (see A. Booter, above). Autonomous NightWatchman - passive notifies authorities, active counteracts intruders. N.B.: My "passive autonomous nightwatchman" is available at your friendly Heath/Zenith store _now_! Sorry, don't have a catalog at hand, or I'd provide ordering information. Mike McLaughlin [Mike, Now that it is FALL, you must be feeling AUTUMNMATED. Autonomous Bosh] ------------------------------ Date: Wed 24 Sep 86 06:57:03-PDT From: Peter G. Neumann Subject: Robottle Management Software? (Wine nought?) To: RISKS@CSL.SRI.COM The following news item appeared in the 15 Sept 1986 issue of Digital Review, roundabout from the 26 June 1985 issue of the Halifax Gazette. But it is RISKY enough to report here. EDINBURGH (Reuters) -- A robot dressed in a black hat and bow tie appeared in court on Tuesday after running amok in a restaurant where it was employed to serve wine. Within its first hour on the job, the secondhand robot became uncontrollable, knocking over furniture, frightening customers and spilling a glass of wine, the court was told. The following day, the robot, exhibited Tuesday in the court, was still incapable of controlling the wine glasses, testimony said. Eventually its head fell into a customer's lap. A tipsy-turvy robot? Did the firsthand know what the secondhand was doing? Asimov's Nth Law of Robotics might read, "A robot must not spill wine on the customers unless enforcing this Law would conflict with Laws 1,2, and 3." But maybe the program instructed the robot to put on "glasses" (ambiguously) so it could see better. Punishment: Send the robot to a OENAL COLONY? [Apologies in advance. I've been up too late recently.] Peter ------------------------------ End of RISKS-FORUM Digest ************************ -------