SECURITY BUG IN INTERACTIVE UNIX SYSV386

[uunet!bria!mike]

In an article, unix386.Convergent.COM!mburg (Mike Burg) writes:
>In article <27B93F44.5606 at tct.uucp>, chip at tct.uucp (Chip Salzenberg) writes:
>> According to jpp at specialix.co.uk (John Pettitt):
>> >We have confirmed that this does indeed work on ISC 2.2 and that SCO
>> >unix does `the right thing' (tm) and core dumps the application.
>> 
>> It is good to see that SCO's engineers, unlike those at ISC and
>> Everex, have an effective grasp on the basic principles of memory
>> protection covered in the first semester of OS design class.
>
>A two sided coin problem...
>
>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.  [...]

Sure I can.  I shelled out a _lot_ of dollars for my operating system.
I have _every_ right to expect my software to be bug-free.  Now, as a
programmer, I know this isn't reality, but in turn, this doesn't justify
it either.

>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
>vendors typically only concentrate on adding more options to the system
>(i.e. X-Windows, more controller card support, networking). They usually
>don't looking into rats mazes like memory managment.  Now, look it from the
>vendors eye's - You'd be expecting for AT&T to ship a somewhat "secure" (if
>you can call it that) product, without serious holes like this one. [...]

Bullocks.  The simple fact that it has come from AT&T does not mean it
excuses a company who is going to refurbish and _resell_ it from going
through it with a fine tooth comb.  Once it's out that door with that
company's name on it, it's not AT&T's problem anymore.

>Logical
>conculsion - concentrate on value and price. But after this, I guess not.
>There's only so much a systems house can concentrate on, and some of them
>are poorly understaffed.

Poor management is not the problem of the customer.  Don't expect me to
whip out my violins and start playing, when not so long ago, I handed
them a hefty check.

>ON THE OTHER HAND, since you are buying a product from the vendors, you'd
>*EXPECT THEM* to sell you a stable product. Kinda of like selling you a 
>new car, then having it going out of control because your kid decided to
>change the radio station.
>
>Face it folks, all versions of Unix for the PC have problems of some kind.
>(Just a matter of what size the explosion will be when it goes off in your
>face) It ain't no Ginsu knive offer - ("It dices, it slices, it's a
>mutlitasking OS and a teeth cleaner! And if you order now you'll receive....")

True enough, but this no reason for the user to not _expect_ a bug-free
version.  Yes, it is pie-in-the-sky, but every company's objective should
be to provide a bug-free product (not a product that has known bugs, or
has them as "features").

How about forcing them to give prior disclosure of all known bugs, _outside_
of the shrink wrap?  How about forcing them to provide _free_ bug-fixes on
a regular basis?  How do you force them?  Don't buy until they do it.  No
company is motivated to change unless it socks 'em in the wallet.

Of course, when you are using PD or freely redistributable code, then you
rolls your dices and takes your chances.  The up side there is that (usually)
you at least have the source.

Now there's an idea!  How about distributing the _source_ with these systems?
Seems to me that long, long ago in a land far, far way, that this was done ...

-- 
Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own.
Title of the week: Systems Engineer    | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
Remember folks: If you can't flame MS-DOS, then what _can_ you flame?