Date: Mon, 17 Aug 1998 02:05:38 +1200 (NZST) From: Andrew McNaughton <andrew@squiz.co.nz> To: Philippe Regnauld <regnauld@deepo.prosa.dk> Cc: rotel@indigo.ie, freebsd-security@FreeBSD.ORG Subject: Re: Fwd: "Using capabilties aaginst shell code" <dps@IO.STARGATE.CO.UK> Message-ID: <Pine.BSF.3.96.980817015746.326O-100000@aniwa.sky> In-Reply-To: <19980816151056.63692@deepo.prosa.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Aug 1998, Philippe Regnauld wrote: > Niall Smart writes: > > > > > > The point was to limit the number of outside attacks on > > > priviledged network daemons. Once the system has been broken > > > into, it's over... "Just keep people out" > > > > I'm not sure what you mean by this; disabling execve doesn't prevent > > outside attacks on network daemons. > > No, but it will prevent buffer overflows that spawn a root shell > (i.e.: qpopper) -- or am I missing something ? As I understand it, this would mean that instead of getting a small piece of code with embedded shell code to execute, the attacker would have to do what they want to by using other system calls, requiring slightly more effort to customize the result of an attack. ie instead of spawning a rootshell, or executing a shell command, the exploit would include commands to perhaps open a file and modify it. Given root perms, and file access, it's not dificult to imagine places where a shell command could be written to disk in order to get it executed soon afterwards. if an interactive shell is needed, then code to modify /etc/master.passwd, or /etc/inetd.conf can be written into object code little bigger than used by current exploits. Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe 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.980817015746.326O-100000>