hubcap@hubcap.UUCP (Mike Marshall) (11/09/88)
Dave Emberson (dre@sun.com) points out how anti-social and ir- responsible Robert Morris was to unleash the worm, and is upset that Mr. Morris is being glorified at the expense of the net (in the form of hundreds of man hours put in by worm eradicators). I understand the point Mr. Emberson is making, but I want to ask him... if HE has known about this hole for four years - why didn't he do something about getting the word out? What has Mr. Emberson done to help me close the hole? Nothing. Mr. Morris has seen to it that the sendmail hole, and several others, are mostly fixed across the whole network. I wonder how many man hours of work it would have taken to fix sendmail, finger and the ftp bug (that wasn't part of the worm, but has come to light, I believe, because of the worm), network wide, under any other circumstances anyone cares to imagine? I wish the network only had people as trustworthy as me on it :-), but you know that there are people out there who will take advant- age of any security hole they find... our only hope is to know about those holes & close them. So, I don't want to applaud Mr. Morris for his poor judgement in unleashing the worm, but I'm glad the holes are fixed now (no thanks to you Mr. Emberson!). -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap DISCLAIMER: If Mr. Emberson has spent the last four years trying to get everyone he knows to turn off "debug" on their send- mails... my apologies to him. It just seems to me that the worm issue points out once again that "security through obscurity" is no security at all.
dre%ember@Sun.COM (David Emberson) (11/09/88)
In article <3481@hubcap.UUCP>, hubcap@hubcap.UUCP (Mike Marshall) writes: > > if HE has known about this hole for four years - why > didn't he do something about getting the word out? What has Mr. > Emberson done to help me close the hole? Nothing. Mr. Morris has > seen to it that the sendmail hole, and several others, are mostly > fixed across the whole network. > Actually, as I pointed out, Matt Bishop (and I presume others) did alert the Berkeley folks about the sendmail bug. I did not know about the one in fingerd. I thought the bug in sendmail was fixed in 4.3BSD. It seems that Ultrix and SunOS are mostly 4.2 based. > DISCLAIMER: If Mr. Emberson has spent the last four years trying > to get everyone he knows to turn off "debug" on their send- > mails... my apologies to him. I have much better things to do with my time, which was one of my points. Dave
pavlov@hscfvax.harvard.edu (G.Pavlov) (11/10/88)
In article <76593@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes: > > > DISCLAIMER: If Mr. Emberson has spent the last four years trying > > to get everyone he knows to turn off "debug" on their send- > > mails... my apologies to him. > > I have much better things to do with my time, which was one of my points. > Great. But time enough to waste discussing Mr. Morris :-) It is hard to accept that our Unix system vendors promote this half-baked attitude. But given the number of people who have stepped forth to pro- claim that they, too, knew about this hole and were kind enough not to muck around with our systems really makes me wonder who takes responsibi- lity for what. I run an end-user shop. I adopted Unix for several reasons, a big one being the flexibility it gives me in selecting hardware and bargaining with vendors. In turn, I expect that I and my people have to invest a lot of time in understanding what we are working with, arcane manuals and all. Fair enough. But to learn that our current and (maybe) future vendors distribute software with known and easily-fixed security bugs is disheartening in the least. There is, to me, a touch of insanity in this security issue. I have seen innumerable messages during the past three years, which state that yes, there are problems, but no, we will not discuss them because that will simply invite potential destruction and havoc. So instead, we learn about them after they are mass-broadcast through the press. Is this the only way ? Or does everyone like me have to spend whatever Unix saves us on developing/paying for the necessary expertise to protect ourselves ? greg pavlov, fstrf, amherst, ny
stjohns@BEAST.DDN.MIL (Mike St. Johns) (11/10/88)
Guys - at this time nothing has been proven about who started this virus. From a libel standpoint the words "alleged" or "as stated in the ABC press" are highly recommended. Mike
rick@SEISMO.CSS.GOV (Rick Adams) (11/11/88)
Lets settle the ftpd issue once and for all. Here are the headers from Bostics message announcing a fix for the ftpd bug: From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) Subject: V1.65 (security problem in ftpd.) Message-ID: <8810312317.AA14287@okeeffe.Berkeley.EDU> Date: 31 Oct 88 23:17:05 GMT Note that this was days BEFORE the first sign of the worm. Therefore, clearly the worm had nothing to do with getting ftpd fixed. --rick
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (11/15/88)
Well, let me throw in my opinion here. With regards to the bugs used by the virus, I, nor any of my friends at UCB knew about them. I don't believe anyone in the CSRG at UCB knew about them. If we had, one of us would have seen to it that it would have been fixed. Just look at the number of security related patches that UCB has put out on comp.bugs.ucb-fixes in the past year. People are serious about fixing bugs in 4.3, but UCB, and I doubt anyone else are out there, are auditing code. The CSRG releases a RESEARCH operating system called Berkeley Unix. It happens to be a very useful release, and many people use it, but it is not a product. There is no software warranty, and it's fairly cheap. So I don't have problems with the CSRG about these bugs; they only do best effort work, and they really don't even need to do that. Where I do find a LOT of problems is what the vendor community is doing here. SUN and DEC produce 'products' out of Berkeley Unix. They charge real money for these products. Yet Sun for example had a serious security bug in one of the network utilities that they knew about for a year (I have the bug report number), and didn't issue a patch at all, but waited for 4.0 to fix the problem. This is ridiculous. DEC is just as bad. It's the vendors who have the responsibility for auditing the code they release. Go scream at SUN for not finding the bug, not at Berkeley. Further, you will always get less buggy code from the CSRG than the vendor community. Why is that? The vendor community normally tracks 4.3 pretty well, though lags by an inordinate period of time often enough. If SUN or DEC finds a bug, they usually tell CSRG about it and fix it. CSRG then fixes it internally, and if appropriate, shortly afterwards releases a bug fix over the network. They also get bug reports from others as well. So CSRG typically fixes bugs quickly. SUN and DEC and company don't usually issue patches; they wait for the next rev. of OS release. Further, often times the development people fix the bug in the code they are using, not in what the 'software manufacturing' group is distributing. So they need to retrofit the fix. What it boils down to is that 4.3 has the fixes out soon after they know about it. The vendors wait huge periods of time unless some sort of crisis develops. You see the recent postings about ftpd bug fixes to comp.bugs.ucb-fixes? Have SUN or DEC released patches yet? Do you really think that bug is only in 4.3? The first thing I do when bringing up a SUN release (I'd do the same thing if I had Vaxstations instead of SUNs) is throw away all the vendor distributed network code and port the latest 4.3 utilities. They work better in general and have fewer bugs (read security problems). Also, this way I have source code, so when UCB issues a bug fix, I can fix it in 5 minutes, as opposed to feverishly beating on my vendor to give me a binary patch that probably hasn't even been produced in the company yet. Folks, for security reasons alone, insist on source code! Mike Padilipsky has a chapter in his book "Elements of Networking Style" called "The Myth of Vendor Support". It's good reading. Anyone from SUN or DEC want to throw rocks at what I've said? I'd love to be proven wrong! Now, about Morris. Firstly, we don't know if he's responsible for this thing. Unless someone has seen a confession, we really don't know if he's the one yet. He may well be, but it's not absolutely clear yet. But if he is the guy, then the FBI MUST be able to sucessfully argue a felony case against him and lock him up. It makes no difference what his intentions were or are. If he did it, he needs to be made an example of. People playing around occaisionally and attempting to crack a system out of a sense of novelty is one thing, but something as large and as well publicized as this virus requires action. The Internet operates fairly freely, but always has this notion of a heavy weight somewhere above that can drop on troublemakers and squash them out of existance. Otherwise what happens is that you get a bunch of urchins attacking things all over the place, and then you have to start restricting the openess of the network, and thereby lessening it's utility. So, when people cause this much trouble, they need to be vigorously prosecuted. Fortunately, I believe the laws here don't require proof of malice, only proof of damage. And I'm sure that the various government agencies involved spent a pile of money (in terms of people's time) to squash this thing, so that shouldn't be hard to prove. Some people are saying that since the virus wasn't intentionally harmful, that all this fuss is really no big deal, and it should be fixed, but is not that big of a deal. As a person who was fighting it fairly early on, I'd have to say that we didn't know it wasn't harmful until we saw the decompiled code a few days later. When we were trying to purge our systems of the thing, we had to assume worst case and that the thing was harmful. We had no reason to assume it wasn't. So we put in a lot of work to squash it. It was the prudent thing to do. And lastly, let's not forget this was a computer problem, not a network problem. Sure the network facilited it's travel, but not all computers on the net were affected. As my boss at NASA HQ said, you don't shut down the Interstate highway system just because some burgler traveled a freeway on the way to robbing someone's house. You beef up security at the house, not close all the off-ramps. If you are concerned about security, make sure your systems are well administered and managed. That's the best thing you can do to avoid problems. Thanks, Milo PS All the usual disclaimers about this not being the opinion of the US Government, Sterling Software, etc... apply here of course...
morgan@Jessica.stanford.edu (RL "Bob" Morgan) (11/22/88)
Milo Medin writes: > ... let's not forget this was a computer problem, not a network problem. I'd like to see people think of it as a "networked computer problem". The point is that our major operating systems, Unix in particular, were designed in the era of unconnected machines, hardwired terminals, and small, computer-knowledgeable user communities. We have seen substantial improvements in ease of use, and we now know how to design communication hardware and software to get reasonable performance from systems attached to large heterogeneous networks. We are still a long way from any general acceptance of the fact that our networked environment requires a fundamental rethinking of the concepts of "users" and "systems", the vigilance with which machines must defend their integrity, and the protocols and services by which reliable communication is accomplished. There's important research going on in these topics. One can only hope that the worm incident will encourage more people to pursue this research, and more computer vendors and system designers to implement systems based on their results. If this doesn't happen, the days of our useful, open networks will be numbered. - RL "Bob" Morgan Networking Systems Stanford University