Date: Mon, 12 Jul 1999 05:38:37 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Peter Wemm <peter@netplex.com.au> Cc: Darren Reed <avalon@coombs.anu.edu.au>, Dag-Erling Smorgrav <des@flood.ping.uio.no>, security@FreeBSD.ORG Subject: Re: Module magic Message-ID: <Pine.BSF.3.96.990712053316.9028A-100000@fledge.watson.org> In-Reply-To: <19990712085857.2B14C8A@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990712053316.9028A-100000>