SECURITY BUG IN INTERACTIVE UNIX SYSV386

[Michael J. Hammel]

In article <113 at calcite.UUCP>, vjs at calcite.UUCP (Vernon Schryver) writes:
> In article <15297 at uudell.dell.com>, mjhammel at Kepler.dell.com (Michael
J. Hammel) writes:
> >     .... Why can't the reseller expect that
> > the original developer had fully tested the original product?
> 
> Have I correctly inferred that the author either works in a testing
> organzation or in a non-technical or at least non-software capacity at Dell?
> 

Test engineer.  Software and Hardware in R&D.

> There is no plausible test that would have found the big, bad bug.  Please
> don't suggest a program that would write to all possible invalid pages in
> the hope of causing something unexpected without providing a way to do that
> quickly enough to be useful, and with a way to reliably detect that
> something more interesting than the FP registers were trashed.
> 

I misrepresented what I was trying to say.  I wasn't suggesting that the
particular bug that has been discussed lately could have been found this
way.  Its just that its oftern hard to point to *exactly* who should be
responsible for some problem when various groups have their fingers in
the code.  Besides, I've learned, as a test engineer, that pointing
doesn't solve the problem.  In fact, it often slows the fixes
development.  As a tester, however, I can't help but point at myself for
a bug that gets by.  After all, its my *job* to find bugs.

> There has been enduring interest in proofs of correctness, ADA, and the
> rest of the "constructive" software reliablity stuff, because testing finds
> only a minority of the bugs.  Testing is good for knowing if an old bug has
> reappeared and for knowing if the build was a complete failure.  That's all.
> 

I wouldn't say its that unimportant.  A major part of testing (it
shouldn't be this way, but often ends up like this) is to uncover the
bugs "on the surface" so the product looks good to the user.  The more
important (often more destructive) bugs take longer to find (either by
automated testing or just be sheer accident) and often don't get found
because of time constraints to get a product to market.  

I suppose it depends on how one views "testing", as a non-technical part
of the development process, or a more sophisticated and integral part of
the development process (thats not a good description, but I think you
understand what I mean).

We should probably move this discussion to comp.software-eng.  Or email
me if you'd liked to talk more about it.

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