Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!chinacat!chip From: chip@chinacat.Unicom.COM (Chip Rosenthal) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Keywords: BAD BUG Message-ID: <1854@chinacat.Unicom.COM> Date: 14 Feb 91 06:13:15 GMT References: <483@stephsf.stephsf.com> <6913@rsiatl.Dixie.Com> Organization: Unicom Systems Development, Austin, TX Lines: 52 <<< extreme heresy alert >>> In article <6913@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >I say "THANK YOU" to all the people involved. The system of free flowing >information work again. John - let me take this a step further. I'm concerned about the bug, but there are other things which worry me more. Granted, this is a horrendous problem. But it is one of a transient nature. It will get fixed, and it will get fixed fairly quickly. What bothers me is the total, absolute breakdown of the ISC support mechanism. Bug reporting through whistleblowing is not acceptable. It troubles me deeply that the entire world has to be rallied to get a bug fixed. Furthermore, if the ISC support mechanism is incapable of handling a bug of this magnitude, I shudder to think how the 99.999% bugs of lesser severity are handled. There is a technical issue which must be addressed, and must be addressed fast. Beyond that, there exists a management issue of a very troubling nature. ISC owes its users a fix. More importantly, ISC owes its users some corrective action. ISC's support is broken and needs to be fixed. I hope when the bug fix is released, we are also provided a corrective action plan by which ISC will fix its support. Currently, Unicom Systems uses one vendor's 3.2 UNIX on 386 boxen. Over the next few months, we will be sorting out our strategy towards a next generation UNIX. I hate to sound cavalier about this problem, but the existence of this bug is not a knockout blow for my evaluations. The fact that ISC's support mechanism has broken down is a knockout. And I can't help but feel there are other folks out there trying to figure out what comes after 3.2. Oh...and to the person who dragged C2 into this. The access requirements of C2 would not prevent this problem - although they might restrict what you can do once you've got your UID of zero. Unfortunately, these restrictions also apply if you get a UID of zero through legitimate means, e.g. `su'. That is the Secureware stuff SCO shoves down your throat and ISC offers as an option would pass on the same damn inconveniences no matter how you get your UID of zero - legitimately or otherwise. C2 certifiabilty is no panacea. In fact, even with SCO's Secureware, you can get root access in 8 seconds if you drop the `mesg n' from /.profile. Secureware doesn't help the fact that remote.unknown is distributed with the wrong permissions, thus allowing unknown systems uucp access. And if you fix this, you still won't get the breakins logged unless you go fixing logfile permissions. If UNIX is broken, no amount of C2 cruft is going to fix it. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. |