Date: Tue, 18 Jan 2000 11:15:49 -0500 (EST) From: Omachonu Ogali <oogali@intranova.net> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: freebsd-security@freebsd.org Subject: Re: Parent Logging Patch for sh(1) Message-ID: <Pine.BSF.4.10.10001181111070.131-100000@hydrant.intranova.net> In-Reply-To: <200001181605.IAA48520@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Pine.BSF.4.10.10001172101390.96286-100000@hydrant.intranova. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10001181111070.131-100000>