SECURITY BUG IN INTERACTIVE UNIX SYSV386

Michael J. Hammel mjhammel at Kepler.dell.com
Wed Feb 20 05:28:37 AEST 1991


In article <446 at bria>,  writes:
> In an article, unix386.Convergent.COM!mburg (Mike Burg) writes:
> >In article <27B93F44.5606 at tct.uucp>, chip at tct.uucp (Chip Salzenberg) writes:
> 
> >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.
> 

This is a poor analogy but...

If Ford buys 1000 bolts to hold its motors in its cars and the bolts
break do you blame Ford or the bolt manufacturer?  Remember (in this
case), testing bolts to see if they will break under pressure is
destructive testing, thus not every bolt could be tested, either by Ford
or the bolt manufacturer.  

The point is that if the reseller of the product does not have the
resources to retest what was delivered by the original developer then
the reseller isn't going to do so.  Why can't the reseller expect that
the original developer had fully tested the original product?  The
reseller should only have to be responsible for what the reseller
modifies (and anything that might get broke because of those
modifications).  However, if the reseller wishes to save face, it will
make every attempt to fix things that it didn't break anyway.  :-)

> >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").
> 
The customer has a right to expect such things, but with large scale
software development its not always possible to provide bug-free code in
a timely and low-cost manner.  Its a trade-off.  Part of the developers
(or resellers) responsibility is to eliminate as many problems as
possible in as short a time frame as possible (both for convenience to
the customer and to beat the competition to the punch).  In some cases,
such as with UNIX, many customers are willing to accept a certain level
of bugs in order to get "the latest-greatest" ASAP.  In other cases,
bug-free software is a necessity (like in communications satellites). 
Notice that versions of UNIX come out much more often and at lower cost
than *most* satellites. ;-)

> 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.
> 

I'm not sure about the bug lists, but I do believe some companies offer
free bug-fixes for current customers.  Major revisions might be at cost
for current customers.  The question is how much can you give away
before you start losing money?  (That is, unfortunately, the reason most
companies are in business.  *sigh*)

Michael J. Hammel        | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham at ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Lead, follow, or get the hell out of the way."



More information about the Comp.unix.sysv386 mailing list