aburt@isis.UUCP (Andrew Burt) (11/06/88)
Several items regarding the Unix security mailing list... (0) Preface to why you're reading this message (1) Status of "old" security list (2) Who is eligible for the "closed" list (3) Justification for having a "closed" list (0) Preface to why you're reading this message The Unix security mailing list is about to be awakened after too long a sleep. A previous posting explained this as well as the reasons and some new procedures the re-awakened list will follow so it can lead a healthy, well-adjusted life. I left some questions unanswered, didn't explain myself well enough on some points, and so forth, hence this posting. The list will be run much the same as it was before, except that routine administrative tasks will be highly automated (whereas before I did most tedious things by hand because many required judgements to be made that a shell script couldn't handle -- so I changed procedures to take out the judgemental problem areas, such as which sites should be used to validate a given applicant). (1) Status of "old" security list I have the sundry programs in place to scan the various messages that I receive. For a closed list the effort to check out each request can really add up, making anyone's busy life even busier -- and the requests are VERY numerous. I'll be posting an announcement on procedures to join in the near future, after I'm relatively convinced what I have in place works. Do NOT send mail to me asking to join! -- Wait until the official procedures are in place. The list will have three distribution points: lll-winken, rutgers, and gatech. I am taking the "current" list members (as of when it was active) and splitting them evenly among the three (done semi-geographically, for what it's worth). Thus old member sites will NOT have to rejoin, but they WILL have to change the address the list is sent to (per previous message's description of effort saving changes). I will send a message to all the old list members in the near future indicating what changes are needed. (2) Who is eligible for the "closed" list Some people have indicated confusion over what I meant by saying only "large" sites can join the list. This represents NO policy change from the previous list, just a restatement of it. I didn't state things clearly, I guess. The intent is to prevent certain kinds of sites from receiving the list, primarily sites that wouldn't be considered trustworthy. E.g., if you were a school and had a network of dozens of workstations, each administered by students, would you really want dozens of students knowing intimate details of how to break security via problems you can't fix (or at least can't fix easily, or in the near future)? Thus the procedure for joining the list calls for a potential member's trustworthiness to be evaluated by someone who is considered trustworthy to the list members, and me in particular. In the old list, before domain naming was in wide use, most sites were uucp and thus could be checked out by talking to nearby uucp sites. Now the balance is shifting such that the work required to check out a site with no uucp connections is formidable. To handle this problem I will be asking potential members to select their references themselves. If I don't like the references, the request will be denied. If I approve the references, then said references will be contacted to approve an applicant. (Any one denial is grounds for denial of admission to the list, thus it takes all references accepting to get accepted to the list.) So the implication is this: I won't deny access to "small" sites just on the grounds of their being small. What I will require is that someone else vouch for them whom I would consider trustworthy, such as another list member or an admin of a reasonably trustworthy site. (3) Justification for having a "closed" list Several people have indicated that a list with exclusive membership is a poor implementation compared to a publicly accessible list. I believe there are compelling arguments in favor of both -- to the extent that two lists are possibly in order, one for secure topics and one for general topics (with the first a subset of the second). At any rate, I first answered these issues in mail to Rahul Dhesi. I'm posting my reply here since I think he covered a good many of the issues I've seen in subsequent postings. =========================================================================== >From Rahul Dhesi by e-mail >Security holes like IFS are quite well-known, so we aren't fooling any >real system intruder by not talking about them openly. I agree with your statement, as far as it goes -- "real" system intruders. I disagree with the spirit of this on the following grounds: If you inform some potential hacker who previously didn't know about this, and it is used to cause harm, a disservice has been done by publicizing it. Real system intruders will know about these holes regardless, as you say. So why create new "real" intruders by informing those who don't know? (See below for the "it will fail to inform some system admins who should be informed" argument.) >Looking through the [contents of a past] issue I concluded that nearly >all of it is either >about security holes that are widely known (but not widely enough, >which gives the intruder a great advantage over the new or overworked >sysadmin) or about issues that aren't really worth keeping secret (such >as general information about public key encryption schemes, or how to >write a password encoding program). About issues not worth keeping secret: yes, perhaps an "open" list to discuss these is in order. About "not widely enough known": Agreed, but I don't think publicizing the information is as likely to cause a new/overworked system admin to pay attention. Publicly known information is likely to be viewed as "not much threat" by the "if it really mattered the vendor of my system would have taken care of it by now" line of thought. The easier "juicy" information is to get, the less importance is attached to it. Just by the fact that the list has "exclusive" membership implies the information contained in it should be viewed as important. >This topic was dicussed quite a bit on Usenet a month or so ago. In >general, the only way you can be sure that sysadmins will know about >security holes and will take action is not by selecting a few of them >and putting them on a mailing list, but by advertising the security >flaws so widely that everybody, sysadmin or not, hears about them again >and again. For one thing, this is the only way you can get people to >pay attention. For another, many of the security flaws that occur >affect individual users. What about systems where there are compelling reasons not to fix the problems? E.g., no newer version of Unix exists; or where there is no money to upgrade; or where the purpose the system serves needs that specific version (consider code developed for a system that won't run on newer Unix versions without effort, which is not always an option); or where only the vendor has the source code in which to fix the problem. I don't know what percentage of the net these would account for, but by advertising their security holes we would be endangering systems that would be more secure if we just kept quiet. I suppose I'm basing my views on two assumptions: (1) That the ratio of potential-hackers to system-admins is much higher with a public list than a private one; and (2) human nature would indicate that potential-hackers are likely to experiment with whatever information comes their way, while system admins are not as likely to fix problems just because they are well known. Combining these, I feel the overall amount of damage done by hackers will rise if the list is public. Hackers are willing to put out significant effort to find holes, whereas system admins are less likely to put out effort to plug holes. Thus I contend that preventing a growth in potential hackers is more beneficial than the harm caused by not informing enough system admins. >For example, the public availability of a password encoding program >(such as pwchkr.c) will encourage users to use uncommon passwords that >could not be found in a dictionary. Secret availability of such a >program will simply mean that easily-found passwords *will* exist, and >the dedicated intruer *will* find them, and most users won't know about >this until it is too late. You really think that the availability of password checking routines will have an effect on what users use for passwords? If anything, it will probably cause them to feel that "if the system takes my password, it must be a safe one" [because code like this must be compiled in since it is so widely available]. If not that, I don't think it will have any effect whatsoever. You forget the "it won't happen to ME" justification people use. I agree that some items like the password checker are not "juicy" tidbits, though. (Particularly since the knowledge of how passwords are encoded is readily available already to any potential hackers who want to fish for passwords. I would still contend, however, that the more potential hackers who are given a program to find easy passwords would cause more easy passwords to be found by hackers than it would prevent easy passwords from being chosen.) So ends my rebuttal. Even though I took your points for what they were, there is an important point you're missing: any system admin can join -- if they have someone vouch that they are trustworthy. Thus what should be widely publicized are not the security holes, but the existence of the (private) list. =========================================================================== The bottom line is that I feel a closed list serves a purpose, and I will continue to administer the list as closed. I do believe an open list is in order as well, but I don't have time to run it. The (alt|comp).unix.security idea is as valid as anything as far as I'm concerned. If a non-newsgroup format is chosen, I will happily route the material from it into the closed list. -- Andrew Burt ncar!isis!aburt "Now go away or I shall taunt you a second time."
clewis@ecicrl.UUCP (Chris Lewis) (11/07/88)
In article <2355@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: >(2) Who is eligible for the "closed" list With the new procedures, could you at least inform the potential applicant whether they were denied or not and why? I applied twice before - once while I was the SA for a major backbone - as far as I was aware, the "approvals" process was only followed thru on once, and I never heard one way or the other on the success of my application. -- Chris Lewis Ferret Mailing list:{uunet!attcan,yunexus,utzoo}!lsuc!gate!eci386!ferret-request {uunet!attcan,uunet,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis (or lsuc!gate!eci386!clewis or lsuc!clewis)
dhesi@bsu-cs.UUCP (Rahul Dhesi) (11/08/88)
In article <2355@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: >Thus what should be widely publicized are not the security holes, but >the existence of the (private) list. And ironically enough, even as this discussion continues, thousands of machines are bitten by a simple security hole in sendmail that could have been fixed *had it been widely publicized*. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
aburt@isis.UUCP (Andrew Burt) (11/09/88)
In article <4646@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <2355@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: >>Thus what should be widely publicized are not the security holes, but >>the existence of the (private) list. > >And ironically enough, even as this discussion continues, thousands of >machines are bitten by a simple security hole in sendmail that could >have been fixed *had it been widely publicized*. Suppose the holes had been publicized before the worm attack. Would public discussion of methods of breaking in have saved any more sites than just posting the patches without explaining what explicit problem they solve? An ideal situation would be this: List member finds hole, submits to list, list members fix, tell vendors, (now the tricky part) vendors send out fixes to sites (particularly to those without source). I'm not against fixing problems, I'm against widely publicizing what those problems are. There are always people who will abuse such information that comes their way. I maintain that stopping N lazy hackers does much more good than informing N (busy) sysadmins what could happen. Inform the N sysadmins how to FIX the problem, sure. But don't give away any more information than is stricly needed to accomplish this. -- Andrew Burt ncar!isis!aburt "Now go away or I shall taunt you a second time."
henry@utzoo.uucp (Henry Spencer) (11/10/88)
In article <4646@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >And ironically enough, even as this discussion continues, thousands of >machines are bitten by a simple security hole in sendmail that could >have been fixed *had it been widely publicized*. Ah, but *would* it have been fixed? (The first reaction around here to the news of the worm was "ho ho, serves them right for running sendmail!". We concluded long ago that sendmail is, for all practical purposes, incomprehensible and unmaintainable, and therefore we do not run it. We continue to be amazed at all the man-years of effort people pour into supporting that abomination.) -- The Earth is our mother. | Henry Spencer at U of Toronto Zoology Our nine months are up. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu