From owner-freebsd-security Tue Jan 18 8:19:29 2000 Delivered-To: freebsd-security@freebsd.org Received: from intranova.net (blacklisted.intranova.net [209.3.31.70]) by hub.freebsd.org (Postfix) with SMTP id C2D4814F17 for ; Tue, 18 Jan 2000 08:18:46 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 6217 invoked from network); 18 Jan 2000 11:20:52 -0000 Received: from hydrant.intranova.net (user24223@209.201.95.10) by blacklisted.intranova.net with SMTP; 18 Jan 2000 11:20:52 -0000 Date: Tue, 18 Jan 2000 11:15:49 -0500 (EST) From: Omachonu Ogali To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@freebsd.org Subject: Re: Parent Logging Patch for sh(1) In-Reply-To: <200001181605.IAA48520@cwsys.cwsent.com> 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 Gotcha. I thought of messing around with kern_exec.c to implement a deny list but I haven't had the time to sit down and study how things work, and also most exploits use /bin/sh to launch their attacks so that's why I pursued sh(1), they go after sh because bash isn't always guaranteed on the target machine, and I haven't seen anyone implement uploading of a shell in the shellcode I've come across. and I agree with you to looking at the big picture. Omachonu Ogali Intranova Networking Group On Tue, 18 Jan 2000, Cy Schubert - ITSD Open Systems Group wrote: > In message net>, O > machonu Ogali writes: > > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > > username logging along with a deny list (/etc/sh.deny). > > > > And in reference to Keith Stevenson's 'So?', if you can determine the > > point of entry in an intrusion you can backtrack to where it originated, > > the main reason I created that patch was to allow a system administrator > > to backtrack in the case of an intrusion. > > A couple of points re the patch: > > 1. Exploits are tailored, e.g. offsets, instructions, etc., for each > targeted platform. All a cracker needs to do is use /bin/csh to > circumvent this on FreeBSD systems. Since most people install > another shell, e.g. bash, exploits can be altered to use other > shells. > > Though I haven't had a chance to think about alternative solutions, > I think we need to step back and look at the bigger picture. > > If I may offer a half-baked idea: Why not a kernel module that > implements the access list at execve(2) for any shell or binary. > The reason for a kernel module is that not everyone would want the > latency that this would cause nor the extra kernel memory. It could > also be a kernel option for static link into the kernel. > > Another idea might be that Robert Watson's logging and ACL's could > be extended to implement this. Robert, care to comment? > > 1a. Related to #1 above, all a cracker needs to do is transfer his own > shell to the victim system thereby circumventing all of #1. In this > case a non-executable stack and jail(2) are your friends. > > A non-executable stack for FreeBSD was discussed here in the past. > I'm not sure whether anyone is implementing this or not under > FreeBSD. > > 2. The patch relies on a /proc filesystem. The proc filesystem has had > security issues in the past, a reason why some don't use it. At the > very least the patch should be #ifdef'd or should check for the > existence of proc being mounted before proceeding. > > Any other ideas? > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca > ITSD > Province of BC > "e**(i*pi)+1=0" > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message