Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!math.fu-berlin.de!opal!tub!gmdtub!prosun!tmh From: tmh@prosun.first.gmd.de (Thomas Hoberg) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Keywords: BAD BUG Message-ID: <517@bigfoot.first.gmd.de> Date: 6 Mar 91 06:38:54 GMT References: <1991Feb12.085747.8468@specialix.co.uk> <27B93F44.5606@tct.uucp> <6027@unix386.Convergent.COM> <1991Feb15.134715.16979@virtech.uucp> Sender: news@bigfoot.first.gmd.de Reply-To: tmh@prosun.first.gmd.de (Thomas Hoberg) Organization: GMD-FIRST, D-1000 Berlin 10 Lines: 62 In article <1991Feb15.134715.16979@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: |> 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. |> 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@bigfoot.first.gmd.de or tmh%gmdtub@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@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET