brant@manta.UUCP (09/25/87)
To Lenny Tropiano: The Unix PC system was clearly designed for use in "non-hostile" environments, where the few security problems that exist (and there are others) are not important. However, there may be people on the net using these machines in environments where security is important, thus we are responsible for not putting those users in jeopardy. As a result, it's irresponsible to post articles giving exact directions for violating system security. Even if you're not personally affected, that doesn't give you the right to post (or encourage others to post) how-to's on system cracking. Your one thoughtless posting certainly did far more damage than good. -- Brant Cheikes ARPA: brant@linc.cis.upenn.edu UUCP: rutgers!cbmvax!cgh!manta!brant Department of Computer and Information Science / University of Pennsylvania
lenny@quincy.UUCP (09/27/87)
In article <149@manta.UUCP>, brant@manta.UUCP (Brant Cheikes) writes: > > The Unix PC system was clearly designed for use in "non-hostile" > environments, where the few security problems that exist (and there > are others) are not important. [...] Almost any environment given the correct circumstances can be "hostile." I wouldn't call displaying you Applications package at a show hostile, but given the person with the know-how... > However, there may be people on the net using these machines in > environments where security is important, thus we are responsible for > not putting those users in jeopardy. As a result, it's irresponsible > to post articles giving exact directions for violating system security. Brant, I was *NOT* giving the people the "DIRECTIONS" for HACKING a machine, on the contrary I was trying to help those people who are not experienced Administrators (especially those who took advantage to the "fire-sale" on 3B1's and know little about there hardware/software) to PROTECT their machine from possible illicit entry. Each and every "flaw" I detailed can be easily protected against with good adminstration. There are others that I know of that are a little more difficult, but nothing is IMPOSSIBLE. > Even if you're not personally affected, that doesn't give you the > right to post (or encourage others to post) how-to's on system cracking. > Your one thoughtless posting certainly did far more damage than good. Those people (me INCLUDED) that leave their machines connected to PHONE lines and are using Usenet HAVE TO BE AWARE of the possibility of problems, and ways to AVOID them. I wasn't "THOUGHTLESS" just CONCERNED! I would like to put my system up as a BBS someday (but I'm afaid of giving anyone SHELL- ACCESS)... The only way to make a totally secure (?) UNIX is do what Gould did ... make a filesystem (or directory) and chroot to it and only put what is necessary to SURVIVE without super-user priviledge. Again, Brant, I'm sorry if I upset you? But I have had very good response (mail-wise) for people who saw my article and thanked me for enlightening them! I'm sorry you weren't one of them. Lenny Tropiano ICUS Adminstrator ...quincy!icus!lenny -- Lenny Tropiano ...seismo!uunet!swlabs!godfre!quincy!lenny -or- American LP Systems, Inc. ...cmcl2!phri!gor!helm!quincy!lenny -or- 1777-18 Veterans Memorial Hwy. ...mtune!quincy!lenny -or Islandia, New York 11722 +1 516-582-5525 ...ihnp4!icus!quincy!lenny
dave@arnold.UUCP (09/28/87)
In article <149@manta.UUCP>, brant@manta.UUCP (Brant Cheikes) writes: > As a result, it's irresponsible to post articles giving exact directions > for violating system security. Even if you're not personally > affected, that doesn't give you the right to post (or encourage others > to post) how-to's on system cracking. Your one thoughtless posting > certainly did far more damage than good. I disagree. Lenny's posting caused me to fix some holes on my system. And triggered some other security related questions that I am going to research. If I can't find the answer anywhere, I might post the question to unix-pc.general or comp.unix.questions. Have you read comp.os.vms recently? There has been alot of heated discussion about security holes. I beleive that unix-pc.general is a perfect place to discuss such issues since we are all unix-pc owner's. Signed, Dave "Please keep me informed on my security holes" Arnold. -- Name: Dave Arnold USmail: 26561 Fresno, Mission Viejo, Ca, 92691 USA DDD: Voice: +1 714 586 5894, Data: +1 714 458 6563 (nuucp) UUCP: ...!uunet!ccicpg!arnold!dave
ignatz@chinet.UUCP (09/29/87)
Brent Cheikes criticized Lenny Tropiano's posting of security holes on the Unix/PC (3B1, etc.) in the referenced article; as both another individual and Lenny have defended the posting item-by-item, I won't go into that here. But I would like to point out that, in general usage, Lenny's posting is quite proper. If you find that some people always leave the keys in their unlocked cars, you buy public service time and have one of those "Take a *chomp* bite out of crime!" commercials. If you discover that any person can calculate the last digits of the telephone company credit card by a simple algorithm, you don't responsibly publish the fact until the algorithm has been changed and new cards issued. In the latter case, "phone phreaks" may publish the algorithm, but responsible individuals neither do so nor perpetuate the handout. Sound familiar? Both are "real world" security situations that have really occurred. In both cases, the operative definition of proper behavior was whether the knowledge of the security hole also included the information necessary to close it, and the person at risk had the means to easily do so. Start locking your car, and take the keys. Ok, simple enough. But you couldn't re-issue your telephone card number; at best, you could cancel it. As another example, fixable security holes have been publicized in such publications as Unix Review. So it is in this case. In all of the security issues Lenny mentioned, there was also a simple fix provided that anyone--with or without a development system--could apply. And there are security holes that are known among those of us who worry about such things, but can't be reasonably fixed without kernel or utility source. *These* do not make it on the net; if they do, they fall under the purview of criticism such as Brent's. I might point out that a common practice in the past was, if you *did* find a security hole that wasn't fixable, the fact that you knew of such a problem might be posted, along with offers to legitimate SA's to snail-mail the problem (and any workarounds, or at least detection methods), if they could prove their legitimacy. When most Unix systems were owned/operated by companies, this was relatively easy--mail a copy of your site license agreement, and/or a note on company letterhead. It's a bit more difficult now, but can still work. Common sense--or, if you will, proper application of "fuzzy logic"--should prevail in deciding what to post, and what to hint at... Dave Ihnat Analysts International Corporation ihnp4!homebru!ignatz || aicchi!ignatz || chinet!ignatz (w) (312) 882-4673 (h) (312) 784-4544 -- Dave Ihnat ihnp4!homebru!ignatz || ihnp4!chinet!ignatz (w) (312) 882-4673
kathy@bakerst.UUCP (09/30/87)
In article <8700178@eta.ETA.COM> lm@eta.UUCP (Larry McVoy) writes: > >The best way to make a system secure is to do exactly what the >poster did: broadcast the information on how to break in. Then it is >*your* problem as a systems administrator to fix it. Lenny said his purpose in posting was to help inexperienced, novice UNIX pc administrators find holes and protect their machines against those holes. Sounds good to me. He says he didn't post directions. (They look like directions to me in two cases out of three, but, hey, I won't quibble.) He also says the holes he mentioned can be easily protected against with good administration. But he doesn't go into any details as to what, exactly, that easy protection and good administration might be. So he helped find a few holes, but he didn't necessarily help anyone protect against those holes. I want to know about holes, too - agreed. Seems to me, though, that, if you really want to be helpful, and if fixes and/or workarounds and/or protections against those holes are really all that simple - and especially if you're especially concerned about inexperienced administrators who may be unfamilar with their hardware and/or software (which is, again, what Lenny said he was concerned about) - then you post fixes or workarounds or administration tips, too, in addition to the holes themselves. That would help people who may not yet have the experience or know-how to follow *your* dictum: "Then it is *your* problem as a systems administrator to fix it." I personally had mixed feelings about the original posting. I've been a little irritated by postings of other people that say, in effect, "There's a TERRIBLE SECURITY HOLE in this machine - but I won't tell you what it is," so I'm left with all these Vague Feelings of Dread about what kinds of gaping holes there are that I don't know about and wouldn't even know to look for, much less how to guard against - but at least I could hope that knowledge about the holes was relatively confined. (Hey, I said I could *hope* :-) I had something of Brant's reaction to Lenny's posting - but I was also interested in seeing the specifics posted for a change, so at least I have some idea where the problem is. Kathy Vincent ------> Home: {ihnp4|mtune|codas|ptsfa}!bakerst!kathy ------> AT&T: {ihnp4|mtune|burl}!wrcola!kathy