22-Sep-86 23:47:17-PDT,14055;000000000000 Mail-From: NEUMANN created at 22-Sep-86 23:45:11 Date: Mon 22 Sep 86 23:45:11-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS-3.62 DIGEST Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Monday, 22 September 1986 Volume 3 : Issue 62 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Massive UNIX breakins at Stanford (Jerry Saltzer, Rob Austein, Andy Freeman, Scott Preece) F-16 Software (Henry Spencer) 1,000,000 lines of correct code? (Stephen Schaefer) [Note: Some BBOARD undigestifiers should now work. Give it a try.] 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 11:04:16 EDT To: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: Massive UNIX breakins at Stanford From: Jerome H. Saltzer In RISKS-3.58, Dave Curry gently chastises Brian Reid: > . . . you asked for it. . . Berkeley networking had nothing to > do with your intruder getting root on your system, that was due purely > to neglect. Granted, once you're a super-user, the Berkeley networking > scheme enables you to invade many, many accounts on many, many machines. And in RISKS-3.59, Scott Preece picks up the same theme, suggesting that Stanford failed by not looking at the problem as one of network security, and, in the light of use of Berkeley software, not enforcing a no-attachment rule for machines that don't batten down the hatches. These two technically- and policy-based responses might be more tenable if the problem had occurred at a military base. But a university is a different environment, and those differences shed some light on environments that will soon begin to emerge in typical commercial and networked home computing settings. And even on military bases. There are two characteristics of the Stanford situation that RISK-observers should keep in mind: 1. Choice of operating system software is made on many factors, not just the quality of the network security features. A university has a lot of reasons for choosing BSD 4.2. Having made that choice, the Berkeley network code, complete with its casual approach to network security, usually follows because the cost of changing it is high and, as Brian noted, its convenience is also high. 2. It is the nature of a university to allow individuals to do their own thing. So insisting that every machine attached to a network must run a certifably secure-from-penetration configuration is counter-strategic. And on a campus where there may be 2000 privately administered Sun III's, MicroVAX-II's, and PC RT's all running BSD 4.2, it is so impractical as to be amusing to hear it proposed. Even the military sites are going to discover soon that configuration control achieved by physical control of every network host is harder than it looks in a world of engineering workstations. Brian's comments are very thoughtful and thought-provoking. He describes expected responses of human beings to typical current-day operating system designs. The observations he makes can't be dismissed so easily. Jerry Saltzer ------------------------------ Date: Mon, 22 Sep 1986 23:03 EDT From: Rob Austein To: RISKS@CSL.SRI.COM Subject: Massive UNIX breakins at Stanford I have to take issue with Scott Preece's statement that "the fault lies in allowing an uncontrolled machine to have full access to the network". This may be a valid approach on a small isolated network or in the military, but it fails horribly in the world that the rest of us have to live in. For example, take a person (me) who is (theoreticly) responsible for what passes for security on up to half a dozen mainframes at MIT (exact number varies). Does he have any control over what machines are put onto the network even across the street on the MIT main campus? Hollow laugh. Let alone machines at Berkeley or (to use our favorite local example) the Banana Junior 6000s belonging to high school students in Sunnyvale, California. As computer networks come into wider use in the private sector, this problem will get worse, not better. I'm waiting to see when AT&T starts offering a long haul packet switched network as common carrier. Rule of thumb: The net is intrinsicly insecure. There's just too much cable out there to police it all. How much knowledge does it take to tap into an ethernet? How much money? I'd imagine that anybody with a BS from a good technical school could do it in a week or so for under $5000 if she set her mind to it. As for NFS... you are arguing my case for me. The NFS approach to security seems bankrupt for just this reason. Same conceptual bug, NFS simply agravates it by making heavier use of the trusted net assumption. Elsewhere in this same issue of RISKS there was some discussion about the dangers of transporting passwords over the net (by somebody other than Scott, I forget who). Right. It's a problem, but it needn't be. Passwords can be tranmitted via public key encryption or some other means. The fact that most passwords are currently transmitted in plaintext is an implementation problem, not a fundamental design issue. A final comment and I'll shut up. With all this talk about security it is important to keep in mind the adage "if it ain't broken, don't fix it". Case in point. We've been running ITS (which has to be one of the -least- secure operating systems ever written) for something like two decades now. We have surprisingly few problems with breakins on ITS. Seems that leaving out all the security code made it a very boring proposition to break in, so almost nobody bothers (either that or they are all scared off when they realize that the "command processor" is an assembly language debugger ... can't imagine why). Worth thinking about. The price paid for security may not be obvious. --Rob Austein ------------------------------ Date: Mon 22 Sep 86 11:07:04-PDT From: Andy Freeman Subject: Massive UNIX breakins at Stanford To: RISKS@CSL.SRI.COM, preece%ccvaxa@GSWD-VMS.ARPA Scott E. Preece writes in RISKS-3.60: reid@decwrl.DEC.COM (Brian Reid) writes: The issue here is that a small leak on some [unknown] inconsequential machine in the dark corners of campus was allowed to spread to other machines because of the networking code. No, you're still blaming the networking code for something it's not supposed to do. The fault lies in allowing an uncontrolled machine to have full access to the network. The NCSC approach to networking has been just that: you can't certify networking code as secure, you can only certify a network of machines AS A SINGLE SYSTEM. That's pretty much the approach of the Berkeley code, with some grafted on protections because there are real-world situations where you have to have some less-controlled machines with restricted access. The addition of NFS makes the single-system model even more necessary. Then NCSC certification means nothing in many (most?) situations. A lot of networks cross adminstrative boundaries. (The exceptions are small companies and military installations.) Even in those that seemingly don't, phone access is often necessary. Network access should be as secure as phone access. Exceptions may choose to disable this protection but many of us won't. (If Brian didn't know about the insecure machine, it wouldn't have had a valid password to access his machine. He'd also have been able to choose what kind of access it had.) The only additional problem that networks pose is the ability to physically disrupt other's communication. -andy [There is some redundancy in these contributions, but each makes some novel points. It is better for you to read selectively than for me to edit. PGN] ------------------------------ Date: 22 Sep 1986 16:24-CST From: "Scott E. Preece" Subject: Massive UNIX breakins at Stanford (RISKS-3.60) To: ANDY@SUSHI.STANFORD.EDU, RISKS%CSL.SRI.COM@CSNET-RELAY.ARPA Andy Freeman writes [in response to my promoting the view of a network as a single system]: > Then NCSC certification means nothing in many (most?) situations. -------- Well, most sites are NOT required to have certified systems (yet?). If they were, they wouldn't be allowed to have non-complying systems. The view as a single system makes the requirements of the security model feasible. You can't have anything in the network that isn't part of your trusted computing base. This seems to be an essential assumption. 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. (IMMEDIATE DISCLAIMER: I am not part of the group working on secure operating systems at Gould; my knowledge of the area is superficial, but I think it's also correct.) [NOTE: The word "NOT" in the first line of this paragraph was interpolated by PGN as the presumed intended meaning.] -------- Network access should be as secure as phone access. Exceptions may choose to disable this protection but many of us won't. (If Brian didn't know about the insecure machine, it wouldn't have had a valid password to access his machine. He'd also have been able to choose what kind of access it had.) The only additional problem that networks pose is the ability to physically disrupt other's communication. -------- 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. scott preece gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece ------------------------------ Date: Mon, 22 Sep 86 18:07:11 PDT From: ihnp4!utzoo!henry@ucbvax.Berkeley.EDU To: ucbvax!CSL.SRI.COM!RISKS Subject: F-16 Software Doug Wade notes: > My comment to this, is what if a 8G limit had been programmed into > the plane (if it had been fly-by-wire)... My first reaction on this was that military aircraft, at least front-line combat types, obviously need a way to override such restrictions in crises, but civilian aircraft shouldn't. Then I remembered the case of the 727 that rolled out of control into a dive a few years ago. The crew finally managed to reduce speed enough to regain control by dropping the landing gear. The plane was at transonic speed at the time -- there was some speculation, later disproven, that it might actually have gone slightly supersonic -- and was undoubtedly far above the official red-line maximum airspeed for the landing gear. It would seem that even airliners might need overrides. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Mon, 22 Sep 86 19:15:31 edt From: Stephen Schaefer To: risks@CSL.SRI.COM Subject: 1,000,000 lines of correct code? The Plain Dealer (Cleveland), Tuesday, September 16, 1986 Excerpted without permission. "Protecting the secrets of success" Dayton(AP) - [Most of article dealing with foreign contractors omitted] [Col. Thomas D.] Fiorino also said a Sept. 5 experiment using two satellites that measured the plume of a rocket exhaust in space and then collided was a success. Some critics, noting the experiment took 1 million lines of computer code, said a full SDI system would take tens or hundreds of millions. Fiorino said there was a computer on board that processed 2 billion operations a second, about four times faster than current "supercomputers." "It did not represent our full technological potential," he said, pointing out that it did not use very high speed integrated circuits still under development. On the one hand, I am incredulous, but on the other, I'd be utterly horrified to find them directing misinformation to the small number of people knowledgeable enough to understand. I hope this ruggedized, portable, Cray class machine is commercially available in a couple years. Failing that, I hope the reporter was simply "innumerate" and heard "billion" for "million" somewhere. I must repeat the quote of Mark Twain by the original poster: "Interesting if true - and interesting anyway." ------------------------------ End of RISKS-FORUM Digest ************************ -------