Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!milano.sw.mcc.com!bigtex!james From: james@bigtex.cactus.org (James Van Artsdalen) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Keywords: BAD BUG Message-ID: <54663@bigtex.cactus.org> Date: 16 Feb 91 18:14:23 GMT References: <1991Feb12.085747.8468@specialix.co.uk> <27B93F44.5606@tct.uucp> <6027@unix386.Convergent.COM> <1991Feb15.134715.16979@virtech.uucp> Reply-To: james@bigtex.cactus.org (James Van Artsdalen) Organization: Institute of Applied Cosmology, Austin TX Lines: 45 In <1991Feb15.134715.16979@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) wrote: > I agree that AT&T should take a major portion of the blame for this bug, > especially in early releases of the OS. I would be careful about placing blame at this point. I have yet to see a strong pattern develop in the postings: clearly ISC has the bug, and it seems Esix does, but current Dell SysVr3 apparently doesn't. There is at least one claim that current AT&T doesn't, and a few that unspecified versions of AT&T does. Key point: some reports say that the 387 emulation actually crashes in systems if the u block is protected. I don't know if the source to the emulator is in the "source" package one receives from AT&T. Fixing the bug might be non-trivial if it is in the emulator, and you don't have source for the emulator. > 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. Absolutely. Getting some programmers to fix bugs is like pulling teeth. People will spend hours describing why they don't want to fix a bug when the actual fix might take fifteen minutes. > 2. I wholeheartly DISAGREE with you posting the source code which > performs the security bypass. [...] Yes a dedicated hacker could > have decoded your explanation and/or the binary and figure out how > to replicate your code, [...] dis(1) is not terribly subtle or difficult to use. It only takes one person to post a dis(1) trace. > 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. The likelyhood that the vendor will actually fix a bug is proportional to the number of frantic phone calls and cancelled orders they receive. The greater the number of people whose system is now painfully at risk, the sooner vendors will deliver a fix. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789