From owner-freebsd-security  Mon Feb 10 17:27:06 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA01481
          for security-outgoing; Mon, 10 Feb 1997 17:27:06 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA01476
          for <freebsd-security@freebsd.org>; Mon, 10 Feb 1997 17:27:01 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id MAA28254; Tue, 11 Feb 1997 12:23:40 +1100
Date: Tue, 11 Feb 1997 12:23:40 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702110123.MAA28254@godzilla.zeta.org.au>
To: dufault@hda.com, roberto@keltia.freenix.fr
Subject: Re: buffer overruns
Cc: freebsd-security@freebsd.org
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>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