John P. Speno recently e-mailed me to point out that the exec stack patch
from Compaq only affects processes running as root or processes that are
suid root. It does not seem to affect processes running under any other
uid. This is problematic because that means that apps that are (for
example) sgid bin are still vulnerable. Also webservers and other daemons
running as other users (e.g. 'nobody') are also still vulnerable -- and if
the daemon isn't running in a chroot() then it may be possible to overflow
a buffer, get a 'nobody' shell and then elevate privs by another attack (a
symlink in /tmp, for example).
Undoubtably this is a design choice to try to make it so that this patch
breaks as few things as possible. Credit to Compaq for trying something
different, but unfortunately it still leaves parts of your system
vulnerable. Compaq really needs to make this configurable, using maybe a
list of uids and gids to protect or simply 'all.' That way Compaq could by
default protect uid root and nobody, gid mem and bin and nobody and
whatever else makes sense by default -- and then that would break as few
things as possible, minimizing Compaq support calls -- but security
conscious admins who knew what they were doing could bump the protection
up to 'all' if they wanted to. Or it would give admins who knew what they
were doing the flexibility to protect their systems, while at the same
time allowing programs that need exec stack to run under a uid which isn't
protected.
And as far as I know the kinds of programs that need exec stack are
compilers. In particular I've had JIT compilers mentioned to me, and I
assume what is going on here is that the compiler sucks in some Java code,
assembles it on the stack and then jumps to it and execs it. Also GCC
uses something called 'trampolines' -- Solar Designer's non-exec-stack
patch for linux actually takes some pains to emulate these things and
allow GCC to run on a machine which has a non-exec stack. I believe that
egcs has removed all the trampolines from the code. I don't actually know
what a 'trampoline' is though -- SD would probably be the person to ask
about them. So far I haven't heard of any system programs that use an
exec stack, and I really wouldn't expect any of them to (it requires you
to generate code in a buffer -- that requires either the functionality of
a compiler or programming on some very interesting drugs...).
I'm pretty sure that Compaq switched from a non-exec stack to an exec
stack when going to 4.0[*] because they wanted these compilers to work
right. Really putting myself in the place of Compaq it's quite obvious
that a default exec stack is a good idea, even if it does open up some
security holes. Otherwise with a default non-exec stack then your
compilers and development environment would be hosed, probably in the kind
of subtle ways that would baffle tech support and cause users to switch to
a less problematic platform like Solaris (putting myself in the place of
the frustrated user in this hypothetical case).
[*] 3.2C is non-exec, plain 4.0 is exec, i don't have access to machines
in between there, i assume it happened when going to 4.0...
On Thu, 22 Apr 1999, Bob Vickers wrote:
> Disabling the executable stack for suid programs regains some safety, but
> as previously mentioned it provides no protection for demons running as
> root.
I believe that it actually does provide protection for daemons running as
root. You can test the behavior of the stack using my stacktest program
that I posted to BUGTRAQ a long time ago:
void main(void) {
int *ad1;
char shellcode[] = "\x01\x80\xfa\x6b"; /* ret */
__asm__("
addq $15,24,$8
stq $8,16($15)
");
printf("%x\n", &ad1);
printf("%x\n", ad1);
printf("%x\n", &shellcode);
printf("%x\n", *ad1);
__asm__("
addq $15,24,$21
jsr $26,($21)
");
printf("jsr worked\n");
}
That program will seg fault on a non-exec stack. If you make it suid root
and run it as a normal user then it should seg fault and in addition if
you su to root that program should also seg fault. Suid/sgid/running as
anything else though will not cause it to seg fault.
--
Lamont Granquist lamontg_at_genome.washington.edu
Dept. of Molecular Biotechnology (206)616-5735 fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontg_at_raven.genome.washington.edu | pgp -fka
Received on Thu Apr 22 1999 - 18:06:13 NZST