SECURITY BUG IN INTERACTIVE UNIX SYSV386

Vernon Schryver vjs at calcite.UUCP
Thu Feb 21 06:08:24 AEST 1991


In article <1991Feb20.124535.10669 at cbnews.att.com>, junk1 at cbnews.att.com (eric.a.olson) writes:
> In article <113 at calcite.UUCP> vjs at calcite.UUCP (Vernon Schryver) writes:
> >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, ...
> 
> 	Oh, give me a break.   SOMEONE must have been responsible
> 	for seeing whether or not writes to illegal pages get
> 	stopped by a segmentation fault.   It doesn't take _that_ 
> 	long to go thru your address space.

Perhaps it would be fast enough.  Please do the math.  Then figure how long
it would take for the test program to do something more than trash the user
process, the "benign" result.

Now please consider what would happen in real life:

    tester:  "Gee, test123456 just found that it can write to address 0xblah."

    test manager:  "Uh, oh!  Call a meeting of all 3rd and 4th level
	engineering and manufacturing managers.  The new release is unusable!".

    ... 13 weeks and 1000 hours of meetings and memos later ...

    1st level engineering manager to tech lead: "Software QA just found that
	    a user process does not get a fault when writing to address 0xblah."
	    What should we do?"

    tech lead:  "Don't have a cow.  It's only where the FP registers are saved."

    ... 2 weeks and 3 meetings later ...

    test manager to tester: "Change test123456 to not worry about address
	0xblah.  It's not a problem."

    ... 6 months later ...

    1000's of USENET posters have a cow.

I've played parts in many of these circuses over the last decades, tho I've
never worked for ISC and have never had the chance for so many USENET
experts to second guess me all at once.

Vernon Schryver,   vjs at calcite.uucp



More information about the Comp.unix.sysv386 mailing list