[ On Tue, April  9, 1996 at 13:49:45 (-0700), Erik E. Fair wrote: ]
> Subject: Re:  easy ways to crash your NetBSD system
>
> The paper is a two or three pager (undated) entitled "On the Security of
> UNIX" by Dennis M. Ritchie, and the first copy I read came with the 7th
> Edition UNIX distribution. I read it on the manual rack in Cory Hall at
> U.C. Berkeley in late 1980. There was an nroff source around for a long
> time in /usr/doc in the distributions, and it is still found in the 4.3 BSD
> manual set that USENIX published: SMM:17

Ah, thank-you!  I thought it was in the original manual, but my re-print
from university does't include volume 2, and of course in the V10
manuals the paper has been replaced by a sligtly updated version of
Grampp&Morris' security paper from the 1984 BSTJ issue on UNIX.  I
thought I had a photocopy, but I can't find it....  Too bad /usr/doc
wasn't included in the V7 manuals freed up by AT&T recently.  I don't
seem to have access to a real 4.3 machine with source any longer.

> That script was known to kill a V6 UNIX from inode table exhaustion; V7 had
> this bug fixed.

Only later versions I think, as I recall bringing some machine at the
U. of Calgary to its knees with a similar inode exaustion.  I thought it
was the PDP-11/60 running the initial V7 release, but it was probably
fixed in the first patch tape.  On the other hand it may have been the
VAX-11/780 running 32V or maybe after it was upgraded to 4.0.  My memory
of some of that time is somewhat foggy!  ;-)

> There is an overall point here: real operating systems do not crash, unless,

Yes, exactly, that is what is most important!  I'm somewhat aghast that
NetBSD is still caught off guard by this rabid-fork() problem.  It seems
as if it should be a simple calculation to ensure that tables which
depend on the size of NPROC are scaled properly as NPROC changes --
certainly these issues are successfully dealt with in most commercial
implementations [of UNIX System V anyway].

Of course the VM leak that persists in -current is another of these
problems that is much more than just annoying.  I do have a customer
running a mail gateway (smail-3) that's been up for 33 days now, and it
claims 10 MB swap used now (50% swap space now gone), and ps only
reports only 2.8 MB under VSZ.  I don't think that machine has started
more than 35,000 processes in the entire time either, most forks of
smail (only 521 deliveries!).

> and return an error). If you want another roaring piece of nonsense, try
> this sometime:
> 
> sh
> $ << `ls`

Yikes!  I had forgot about that!  BTW, it takes a good 20 seconds to
kill off the offending shell on a diskless Sun-3/60 running SunOS-4.1.1
(though some of that was dumping the 2.2MB core over NFS)!  ;-)

> This is not just a question of quality or bugs - it's also a security
> issue; please note the name of the paper in which Ritchie discussed kernel
> resource exhaustion handling, cited above. To the extent that we'd like to
> add new and sexy security technology to the system (e.g. IPsec), we gotta
> make sure the mundane stuff is done too, or the sexy stuff won't really
> improve security. Think about the fingerd bug that the 1988 Morris worm
> exploited - there's an example of "software engineering as a security
> issue" if I ever saw one.

Exactly!

And then there's Ken Thompson's ACM lecture on the compiler virus (and
Tom Duff's paper on similar virii in Computing Systems).  I hope someone
in this vast group has time to occasionally really read and understand
the source for good chunks of the system and tries to ensure such
nasties aren't being snuck in.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>