Date: Tue, 11 Feb 1997 12:23:40 +1100 From: Bruce Evans <bde@zeta.org.au> To: dufault@hda.com, roberto@keltia.freenix.fr Cc: freebsd-security@freebsd.org Subject: Re: buffer overruns Message-ID: <199702110123.MAA28254@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Is the stack executable? I've been assuming the exploits modify Yes. >the stack to return to a built up call to "system" or something >else in the library with their own args setup. I've been assuming >that executing data isn't part of modern exploits. It is, at least under FreeBSD and (apparently) under Linux. FreeBSD still uses the 1980'ish method of putting the signal trampoline on the user stack to execute, so the code segment has to extend to nearly the end of the user stack, although the code segment can be completely separate on i386's. In fact, the code segment still extends to the end of the user area (2 user-readable, user-executable pages above the user stack) to support the 1970'ish (:-) method of putting the signal trampoline in the user area. >Has anyone seen modifications to gcc to generate guard bands around >automatics and stack check sequences? The automatics can be checked >when they come into / go out of existence, and stack integrity at >return time. It won't stop the exploits, but it will make them >harder, and you will get "security" dumps from setuid programs if >you require that setuid programs be compiled that way (and linked >against a separate "secure" library compiled that way also). I haven't seen anything. Perhaps something could be hacked into the existing profiling support. I added a -mprofiler-epilogue call to FreeBSD's gcc. It results in calls to a profiling function `mexitcount' before each normal function returns. This would be a good to check the return address and other stuff in the caller's frame. >You could even hack things so that setuid would fail for >"insecure" executables. How about a masks for acceptable syscalls in the kernel and in non-auto storage. Some setuid processes could give up privilege for critical syscalls like exec() and mmap() early and permanently. The user-mode mask would be set when critical functions are called and cleared when the functions return normally. General stack exploits would have difficulties finding the mask. Encrypt the mask to make this harder. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702110123.MAA28254>