From owner-freebsd-security Mon Jul 12 2:39:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2600814C18 for ; Mon, 12 Jul 1999 02:39:30 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA09080; Mon, 12 Jul 1999 05:38:37 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 12 Jul 1999 05:38:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Peter Wemm Cc: Darren Reed , Dag-Erling Smorgrav , security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <19990712085857.2B14C8A@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Peter Wemm wrote: > Darren Reed wrote: > > In some mail from Dag-Erling Smorgrav, sie said: > > > > > > Thought this'd be of interest to this list: > > > > > > http://thc.pimmel.com/files/thc/bsdkern.html > > > > So what ? > > > > Nothing in that document is "new" although it might be the > > first time it's been documented for script-kiddies. > > Yeah, the main worrying thing about it is the hard coding of internal data > structures and bypassing of proper interfaces. I'm half thinking about > doing a couple of arbitary rearrangements of some internal (opaque) data > structures to make their life a bit more exciting. I'd rather a box panic > and burn if a script kiddie gets in and tries to use some of these > ``techniques'' than have it run whatever they like undetected. This will > be totally harmless to the existing modules since the data structures are > not used outside kern_*.c. Have to be a little careful with structs such as struct proc that have zero-able and copy-able sections at fork(). As using securelevels to disable module loading is currently not really too feasible for the mass-market, the best thing to do might just be to provide a sysctl that turns off module loading, and encourage server users to toggle the sysctl once all needed modules are loaded to prevent nasty-modules from being loaded. Needless to say, it would be a one-way toggle. :-) Needless to say, nothing the document says is new (presumably many of us have written modules just like these to experiment with them, and the techniques of syscall intercepting and replacement are useful from the perspective of securing the system, as well as breaking it :-). At least that I've seen, and no doubt it will suffer from the rapid development of the module interface (i.e., dependencies on modules, etc). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message