hutch@net1.ucsd.edu (Jim Hutchison) (11/07/88)
Unix is not a "secure" system. No system attached to a network is
entirely secure. Valid and illicit network transactions can be
identical. A casual shell expansion here, a little flexibility in
input for a mailer there, ... the system not designed to stop intruders
lets them in. For security, put the machine in a red Tempest can and
seal it up tight. Or looked at in another light, more damage could
have been done with a modem and 10 popular women's names!
The type of hole through which a recent Deutschlander climbed, still
exists. The casual hole. A broken piece of software that did not
get updated, or came back from a backup when the controller scrawled
wild accusations across the system partition. Human error is real,
it can not be ignored. Most importantly, it will happen to you.
Locks are for children and honest people. It is nice to know that
there are "locks" on the doors of the system. I don't go out cracking
security, I'm simply not interested. Almost anyone *can* crack
security. BSD security is not particulary more ventilated than SysVr*,
or VMS. Software has bugs. Get it. If it fails to deliver a letter,
or lets in "the man with no name", it's still just a bug.
Hopefully this article has not fed any hysteria.
/* Jim Hutchison UUCP: {dcdwest,ucbvax}!cs!net1!hutch
ARPA: JHutchison@ucsd.edu
These are my opinions, and now you have your perceptions of them. */khb@SUN.COM (Keith Bierman - Sun Tactical Engineering) (11/09/88)
In article <829@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes: >Just a note regarding the recent illness of the internet, etc. I am sure >that the perpetrator will be found and almost certainly punished in some >way. But I for one thank the guy. ^^^^^^^^^^^^^^^^^^^^^^ > stuff deleted >You just can't convince some people that something is possible until it is >too late. I have seen some postings on the net about "Other people know >how to do this too, but we are too polite to do it". Well, that is not >sufficient. If you know it can happen, why was this gaping hole left in? >Lucky for us it was a reasonably responsible person who did this instead of >a juvenile "cracker" who thought "Oh boy, wouldn't it be neat to crash >every machine on the internet and delete all their files." Obviously things >could have been a lot worse. The fact that these holes were left in and not >fixed is a problem. Those who were aware of the problem and did not do >anything about it are just as guilty as the person who did. > I know how to get drunk and drive a truck right through a schoolyard. This would serve to demonstrate why we shouldn't serve such beverages, and why schools should be protected with huge fences (concrete) and armed guards. Of course not everyone wants to live that way. Note that only universities and research instuitions got infected. "real" companies have armed guards patrolling the net. This costs $$ This infestation will result in more public hysteria, and will raise the cost of maintaining the net. Arbitrary levels of security are possible, but do we wish to bear the costs ? For comparison, consider: Do we want armed guards at every freeway on-ramp ? Every corner ? People who unleash viruses should be shot, or otherwise done away with. (btw: the excuse that it was an experiment is pretty lame, would we feel sympathy for a biological reseacher who did the same thing ? Experiments should remain in the lab. Not the "real" world).
scott@attcan.UUCP (Scott MacQuarrie) (11/09/88)
There is a product available from AT&T's Federal Systems group called MLS (Multi-Level Security) which provides B1-level security in a System V Release 3.1 environment. I have seen the product on a 3B2, it's availablity from other vendors would probably require work by those vendors. (Yes Henry, we might even help them do that :-) ). Scott MacQuarrie AT&T Canada Inc. uunet!attcan!scott p.s. Opinions are my own.
bill@UHCCUX.UHCC.HAWAII.EDU (William J. King) (11/10/88)
Well, What would prescribe as just punishment for the Wiz of Cornell?
ron@ron.rutgers.edu (Ron Natalie) (11/10/88)
...and I have worked on IBM's B2 product, but I fail to see what that has to do with the discussion. A bug in either product can cause it to fail to do what it is supposed to do. In the development group the Trusted System Programmer frequently has backdoor functions to bypass the Mandatory Access Control on the test system that one hopes are never installed in the field (this is much akin to the exploited DEBUG bug in the BSD systems). And any secure workstation that's plugged into a network is very suspect. I believe NCSC won't even talk to you if you put an ethernet card in the workstation. -Ron
hal@GATEWAY.MITRE.ORG (Hal Feinstein) (11/11/88)
>There is a product available from AT&T's Federal Systems group called >MLS (Multi-Level Security) which provides B1-level security in a System V >Release 3.1 environment. I have seen the product on a 3B2, it's availablity >from other vendors would probably require work by those vendors. (Yes Henry, >we might even help them do that :-) ). >p.s. Opinions are my own. I'm sure its a fine product. Would it help with this worm? How?
ncoverby@ndsuvax.UUCP (Glen Overby) (11/14/88)
In article <1727@cadre.dsl.PITTSBURGH.EDU> sean@cadre.dsl.pittsburgh.edu (Sean McLinden) writes: >It is clear from Rick Adams' comments that 'not wanting to tip anyone off' >is no excuse. Even binary-only sites can be protected fairly rapidly if >the appropriate channels are used. This sort of thing has been a pretty big issue lately, so I thought I'd chip in a few comments. If information about bugs (or, should I say, "misfeatures") in Unix (or really any OS) should not be publicly disclosed to protect those who either do not or can not repair them, then HOW should such "classified" information be distributed to those who want/need it, and can and will fix the holes? Not but a few weeks ago there was a "discussion" on one of the news.* groups about the Security mailing list (there are two of them, but thats irrevalent here) which is restricted to "trusted" people (those who are "root" on a "major machine" -- whatever that means). Now, if information about security bugs is too risky for distribution among that elite group of "system gods", then should that information be exchanged over network mail systems at all? (e.g. to 4bsd-bugs@ucbvax). I think all of this sort of information should be distributed at least over the private security forum; Vendor releases just aren't frequent enough to fix these problems in a timely manner. Glen Overby ncoverby@plains.nodak.edu uunet!ndsuvax!ncoverby ncoverby@ndsuvax (Bitnet)
eichin@ATHENA.MIT.EDU (Mark W. Eichin) (11/17/88)
>Date: 13 Nov 88 23:24:04 GMT >From: elsie!ado@cvl.umd.edu (Arthur David Olson) >> I'll bet the KGB are laughing their asses off. >That depends on whether kremvax was running 4.3BSD or Ultrix. % bindtest > hkremvax.mit.edu res_mkquery(0, kremvax.mit.edu, 1, 13) QUESTIONS: KREMVAX.MIT.EDU, type = HINFO, class = IN ANSWERS: KREMVAX.MIT.EDU type = HINFO, class = IN, ttl = 21600, dlen = 16 CPU=VAXSTATION OS=UNIX > Actually, it is a VS2000, running 4.3BSD+NFS (MIT Project Athena modifications...) It was not infected (in fact, I used it throughout the infection, on the MIT decompiling team.) Mark Eichin <eichin@athena.mit.edu> SIPB Member & Project Athena ``Watchmaker'' ps. Yes, I chose the name just to be able to answer such a question. :-)
ado@elsie.UUCP (Arthur David Olson) (11/18/88)
Thanks for the reply! So much for my followup article about how kremvax didn't get infected because the KGB had not only disabled sendmail's debug option but had removed sendmail entirely as a security threat. (Another possibility would have been that kremvax ran neither Ultrix or MORE/bsd 4.3 on its VAX, but rather MS-DOS. Muscovite Socialist DOS?) --ado
hbo@sbphy.ucsb.edu (Howard B. Owen) (11/20/88)
In article <CMM.0.88.595111611.bill@uhccux.uhcc.hawaii.edu>, bill@UHCCUX.UHCC.HAWAII.EDU (William J. King) writes... >Well, > What would prescribe as just punishment for the Wiz of Cornell? A friend of mine at Berkeley says they suggested to Cornell that the guilty party be suspended for one year, then forced to rewrite sendmail. When I intimated I wasn't too happy with that idea, my friend replied "I didn't say anyone had to run it!" -- Howard Owen, Computer Systems Manager internet: hbo@sbphy.ucsb.edu Physics Computer Services BITNET: HBO@SBITP.BITNET University of California, Santa Barbara HEPNET/SPAN: SBPHY::HBO "I am not a pay TV service!" uucp:{The World}!ucbvax!hub!hbo