Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Keywords: BAD BUG Message-ID: <1991Feb15.134715.16979@virtech.uucp> Date: 15 Feb 91 13:47:15 GMT References: <1991Feb12.085747.8468@specialix.co.uk> <27B93F44.5606@tct.uucp> <6027@unix386.Convergent.COM> Organization: Virtual Technologies Inc. Lines: 48 mburg@unix386.Convergent.COM (Mike Burg) writes: > >From a view of a person who has work for various Unix system houses - >you can't really blame ISC, ESIX, or any other vendors that current has the >bug in it's release. I think the blame should be placed on AT&T. They are the >ones who are (were) shipping the base source with the bug. Most AT&T UNIX I agree that AT&T should take a major portion of the blame for this bug, especially in early releases of the OS. HOWEVER, ISC plainly knew about the but when it released 2.2 and instead of fixing the problem they threw together a kludge that would only work if you had a numeric co-processor installed in the machine. That was what I consider a very big *mistake* on ISC's part (I would hazard a *GUESS* that it was probably a consious decision that the time that would be spent to fix the problem that was relatively unknown could be better spent fixing other problems. Note that I would strongly disagree with this decision). That said, ISC (and reportedly ESIX) have reacted quickly and promissed a fix disk for each version of the OS RSN. ESIX has reportedly said it will post the fix to this newsgroup. ISC *should* do the same, but has said that they will only release the fix via thier normal fixdisk distribution mechanism. Now, as to the original posting about the bug - 1. From what you said (you tried to get ISC to fix it for the past 6 months) I agree with your action of posting about the problem to the net so that you could force ISC to fix the problem. This was apparently needed. 2. I wholeheartly DISAGREE with you posting the source code which performs the security bypass. You could have just posted the uuencoded binary which would have been enough to prove your point without making it extremely easy for any two bit user to obtain privileged access. Yes a dedicated hacker could have decoded your explanation and/or the binary and figure out how to replicate your code, but the number of those is MUCH less than the number of people who can now violate the security of the system using your posted code. POSTING THE CODE WAS DEAD WRONG. Enough said. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170