SECURITY BUG IN INTERACTIVE UNIX SYSV386

[Conor P. Cahill]

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. 

Enough said.
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170