**************************************************************************** >C O M P U T E R U N D E R G R O U N D< >D I G E S T< *** Volume 3, Issue #3.00 (January 6, 1991) ** **************************************************************************** MODERATORS: Jim Thomas / Gordon Meyer (TK0JUT2@NIU.bitnet) ARCHIVISTS: Bob Krause / Alex Smith / Bob Kusumoto BYTEMASTER: Brendan Kehoe USENET readers can currently receive CuD as alt.society.cu-digest. Anonymous ftp sites: (1) ftp.cs.widener.edu (2) cudarch@chsun1.uchicago.edu E-mail server: archive-server@chsun1.uchicago.edu. COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing information among computerists and to the presentation and debate of diverse views. CuD material may be reprinted as long as the source is cited. Some authors, however, do copyright their material, and those authors should be contacted for reprint permission. It is assumed that non-personal mail to the moderators may be reprinted unless otherwise specified. Readers are encouraged to submit reasoned articles relating to the Computer Underground. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DISCLAIMER: The views represented herein do not necessarily represent the views of the moderators. Contributors assume all responsibility for assuring that articles submitted do not violate copyright protections. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ From: Name withheld Subject: Security on the Net Date: Sun, 23 Dec 90 17:04:49 -0500 ******************************************************************** *** CuD #3.00: File 5 of 6: Security on the Net *** ******************************************************************** COPS is a unix security package that runs through a checklist of sorts looking for common flaws in system security. I polled a security mailing list and got about 40 responses to a selected number of questions dealing with security; it might be useful for inclusion on how the net (at least some of the security minded ones) view security. The answers to these questions shaped some of the philosophies of COPS and might be indicative of the type of security tools to be developed in the future. My questions start with a number and a ")". 1) What kinds of problems should a software security system (SSS) such as COPS check for? (Mention specific examples, if you can.) Just about everyone agreed that the more things checked, the better. Some specific wants of items I didn't mention, more or less in the order of # of requests: Some kind of _secure_ checksum method for checking up on binary files. Checking binaries for known security problems - sendmail, fingerd, ftpd, ect. Checking the validity of the _format_ of key files rather than merely checking if they are writable. Checking for potential trojan horses; files such as "ls" in a users account. Finding things hidden under mount points. Keeping track of accounts in a seperate file from /etc/passwd and run periodic checks to see if any accounts have been added by any unauthorized user. Report unusual system activity, such as burning lots of CPU time. Record unsuccessful login attempts and su's to root, when and by whom if possible. 2) Are there any security problems too sensitive to be checked by a SSS? That is, what things should *not* be built into a SSS? Boy, this was a landslide. Over 90% said NO, and not only no, but basically "Hell No". The only concerns I got were against password cracking and problems that could not be easily fixed. There was also a small amount of concern about limiting access to root, but most realized that no matter what, the benifits would outweigh any losses if the programs were put out. 3) What should the primary goal of a SSS be -- discovering as many security holes as possible in a given system (including bugs or design flaws that may not be easily fixed -- especially without source code), or merely uncovering correctable errors (due to ignorance, carelessness, etc)? Another landslide. Of all the responses, only one person objected to finding all holes, although a few did say that finding the fixable holes was top priority. One view: My use for an SSS is as a system monitor, not as a diagnostic tool. I suppose the diagnostic version also has its uses, but writing and distributing such a program is asking for trouble. I don't see anything wrong with writing it and distributing only the binaries. 4) Do you feel that SSS are a security threat themselves? Some dissent begins to show.... It was almost even here, with the no's beating out the yes's by a single vote. However, 2/3 of the yes votes qualified there answer by stating something like "a tool can be misused" and whatnot. Here are some typical responses: Of course. They point to way for bad guys. Such is life. They are a tool. They have the potential for anything. The security threat lies in how they are used.... No, as long as they don't breed complacency. Just by running a SSS each night should not make you thinks your systems are secure. Fire is also dangerous but VERY useful. 5) Do you think that the SSS should be restricted to be used only by system administrators (or other people in charge), or should they be accessible to all? Here's where the problems start :-) Everyone wants as many features as possible, but quite a few of you don't want anyone else to have it. Hmm... Out of 35 responses on this question: 12 - Yes, only SA's. 10 - No. 6 - It would be nice to have it restricted, but... How? 5 - Have two versions; one restricted, one not. Needless to say, the dangerous stuff should go in the first. 1 - Restrict only parts that detect bugs/whatever that cannot be repaired. 1 - Argh! Help! Some quotable quotes: I don't see how it could be restricted. Admins, etc only. (possibly said because I'm an admin. From an intellectual standpoint, I would want to know about this stuff even if I was just a user) I think the SSS should be restricted to system administrators with the realisation that others can probably get their hands on the code if they want to. Definitely available to all, SA's can be as lazy as anyone and should not be allowed to hide behind a veil of secrecy if, in doing so, they expose the systems they administer. It seems to me that only an "administrator type" will have sufficient privilege levels to make _effective_ use of such a tool. Ordinary users may be able to garner _some_ benefit though, if run on their own files. If possible, can there be an "administrator" mode and a (restriced/limited) "user" mode? (and finally, my personal favorite...) I think that a check for a hole that can't be closed shouldn't be a part of the check, if that hole is widespread. I have no examples of any such hole, but a weak spot that can't be closed and has no workaround is one of the few candidates for the security by secrecy concept. I have mixed feelings about this, but if I can't fix the hole, I'd rather not have it's existence be "public" knowledge. A freely available routine to locate the hole would spread it's existence far and wide.....(?) But, if I didn't know about it beforehand then it would be good to have a tool to tell me it existed. Gads, I hate moral conflicts! 6) When a SSS finds a security flaw in a system, do you want it to indicate how they flaw could be used to compromise your system, or would you just accept the conclusion and apply a fix? This question was ill worded and gramatically incorrect, but still managed to conjure up a lot of comments. Some thought it was asking if the system should apply a fix. In any case, almost 3/4 said Yes, indicate exactly how to exploit any potential hole. As usual, there were a few with reservations about the info getting out, but.... Here are some of the more interesting comments: (Think about this one!) *I* would like to know to futher my knowledge of Unix, but more importantly to make sure that the version I have was not modified by a cracker to put security holes *into* a system. (That'd be sneaky :-) Security by obfuscation doesn't work. By definition, a SSS is a software system, and therefore has bugs in it. If it reported a problem which would cause quite a bit of inconvenience if fixed, or would be difficult to fix, then I would be much more apt to make the fix if I knew how the problem could be exploited. This is important, because many, if not most, sites require only a moderate level of security, and many security holes are fiendishly difficult to exploit. We cannot assume that end-purchasers of a system can be as aware of the internal workings of a system as the designers of the system (or SSS) are. If a security flaw is discovered, the administrators need to be informed about what changes are necessary to remove that flaw, and what repercussions they may have. Imagine a SSS that knew sendmail(8) was a security flaw allowing a worm to enter systems. It would report that sendmail is a security flaw, please disable it like.... If the vendor had released a patch, and the SSS didn't know how it, the administrator (in blind faith to this SSS program) might disable a *very* useful program unnecessarily. 7) Do you think that there is too much, not enough, or just about the right amount of concern over computer security? How about at your computer site? At other sites? The "not enough"s won, but not by much. I thought that given the paranoia of a security group, this would be a larger victory. Lots of people said it depends -- on the type of facility, the size, etc. Large sites seem to have a healthier view of security (paranoia :-)) than smaller/non-governmental. Only 4 or 5 said there was enough concern. A couple of people mentioned _The Cuckoo's Egg_ as suggested reading (I heartily agree.) More quotes: (I don't know if the next answer is true, but I like it anyway!) This is really a deep philosophical question---something to talk about over a few beers at the bar, but not here. I think it's a site dependent problem, and all the above are true: too much, too little, and just right. Computer is not a "one size fits all" situation. Having offered that opinion, I think an assessment of my site or other sites is extraneous, and I will reserve that opinion. ... more attention to unauthorized use of the networks. 8) Do you think that there should be a ruling body that governs and enforces rules and regulations of the net -- sort of a net.police? Some of you wondered what this had to do with software security, but just about everyone answered anyway. This one scared me! The "No's" only beat out the "yes's" by one vote. Yikes! Maybe I'm from the old school of thought, but.... Several people said that it couldn't be done anyway; a couple mentioned they a CERT-like agency to help out, but not control, and finally two said that the laws and government were already there to do this. It's there, defacto. The free market is working pretty well. Absolutely. I quarrel with the "net.police" designation, per se, of course, as do many others. But perhaps something more like a recognized trade association, and providing similar services. Also, it is time that the basic duties which must be reasonably performed by a site in order for it to remain on the net should become a requirement rather than a matter of individual whim. Yuck! This is very distasteful to me. It will probably be necessary though as more and more people participate in the net. Enforcement will have to be judicious until secure networking is developed and implemented generally. No. Aside from the fact that it'd never work, I like Usenet as an anarchy. It has some rough edges, but for the most part it works. What does this question have to do with SSS-type programs? Enforcement will be tough and may hold back legitimate users. But we have to start somewhere. So I suppose that I agree with having net.police, as long as they don't turn things into a police.state.net. 9) Do you believe that breaking into other people's systems should continue to be against the law? Only one said "no", and s/he had a smiley following the answer. But there were some of you who voiced concern that it wasn't really against the law to begin with. In _The Cuckoo's Nest_, Cliff Stoll talked about a (Canadian, I think) case that the only reason the cracker was prosecuted was for stealing electricity! Less than a watt or something. A few of you mentioned denial of services as being a just reason, but what if they break in only at night, when no one else is on, and they really don't take anything at all? Should that be less punishable than someone who sucks away user CPU/disk/whatever? Breakins should be encouraged and rewarded (1/2 :-). Yes. Unquestionably. However, those laws should not attempt to regulate inter-system traffic to cause these things to happen. Yes - and as a felony in all cases, without exception. Yes but murder, rape, robbery... are more important and laws and sentencing should reflect this. There are some around who want to treat cracking as a capital crime! Yes, from the denial of services standpoint. I pay $XXX,XXX.XX for a system, and joe blow slides in and sucks away at those resources, there should be a nontrivial penalty for getting caught. Don't behead the guy, but monetary fines or community service would be just fine. I don't know. I'm not a philosopher. Certainly causing damage to others is wrong, including denial of service, compromising sensitive info, or whatever. I'm concerned though that clamping down on young kids will discourage them from becoming computer geeks. I think we need to encourage our young people to become technically literate. If we don't become a more expert society we can kiss it goodbye; all we'll have left is our military solutions, like some brainless jock bully... I'm not sure that it is everywhere - but: Yes. Should attempting to break in be against the law: No. Is this vague: Yes. I did not know that it was. The laws about it have not been tested and are vague and unclear. You need to be very clear about what the laws are going to do. **HELL FUCKING YES** Those of us who started in UNIX years ago have for the most part *always* respected others!! This I can't stress strong enough. 10) Is your site academic, government, or commercial in nature? Just over 1/2 of those that answered claimed university ties, with about 1/4 being commercial, 1/6 government, a few research sites, and a couple that were a mixture. Sites included Sun, AT&T, SCO (Xenix), the DoD, and the Army, among others. (Guess where this one came from :-) Research. We invented Unix. Academic with commercial applications. Primarily academic, but we are part of the government. Academic, except when collecting student fees *) *) ******************************************************************** >> END OF THIS FILE << ***************************************************************************