SECURITY BUG IN INTERACTIVE UNIX SYSV386

[Thomas Hoberg]

In article <1991Feb15.134715.16979 at virtech.uucp>, cpcahil at virtech.uucp (Conor P. Cahill) writes:
|> mburg at 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. 
|>
Hmm, I don't run *ANY* binaries, that come off the net, especially any that are
supposed to exercise security holes. While source code distribution doesn't
make viruses or trojans impossible, I tend to think it makes them harder to hide.
|> Enough said.
ditto
|> -- 
|> Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
|> uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
|>                                                 Sterling, VA 22170 

-- 
----
Thomas M. Hoberg   | UUCP: tmh at bigfoot.first.gmd.de  or  tmh%gmdtub at tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET at DB0TUI11 or
+49-30-254 99 160  |         tmh at tub.BITNET