Bugtraq mailing list archives
Re: SMASHING THE STACK: PREVENTION?
From: abelits () phobos illtel denver co us (Alex Belits)
Date: Mon, 28 Apr 1997 19:17:46 -0700
For all I know there are very few SUID 0 programs which invoke execXXX routines to spawn a shell. Getty is probably the only significant SUID program which starts a shell, so it should be pretty easy to introduce additional checks: for instance if the SUID program tries to exec any of the shells: csh, bash, ksh,...., just returns an error and logs the real_user_id somewhere. Any comment?
cp /bin/sh whatever IMHO all those checks can result only in more confusion for a programmer and almost unnoticeable trouble for intruder. Even non-executable stack will be useless because it will just cause exploits to place shellcode somewhere else, and even making everything non-executable except actual code can't guarantee anything because a lot of suid programs, as it was mentioned before, have code suitable for intruder's needs already. I see only three solutions: 1. (obvious) Fix the code. Probably will take a lot of time, but should be done anyway. 2. Reduce the amount of suid root code. sendmail and xlock have absolutely no need to run as a single large piece of code that keeps root privileges all the time and can be started by any user. They can be easily split into large and possibly not thoroughly buffer-checked part and small secure setuid program that will do only what supposed to be done as root. wtmp is also ridiculous reason to be setuid root, xterm can just fine be split into terminal/login handler that will be set{u|g}id to tty (or whatever but root/wheel) and vt100/tek emulator. ps and friends can follow linux example and use /proc that shouldn't be too hard to implement in any system, and only things like ping and su can't be changed that way, but those ones aren't hard to make secure anyway (AFAIK, they already are well written everywhere). 3. Some mechanism to increase privileges for certain parts of code in certain executables. Should be really hard and will require modification of the kernel and use of some authentication mechanism in it, so some setuid utility (modified linker?) will start, authenticate itself with the kernel, and then kernel will allow that process to change its uid/gid between some set of uids/gids from some parts of code or only from some libraries, so whatever will be exec'ed by that utility, will keep that ability until the next exec or exit that will invalidate such privilege. It still will be possible to feed something to that program so privileged code will do something "wrong" if it isn't designed to be secure, but in that case security will depend mostly on privileged routines, not on everything around equally. -- Alex
Current thread:
- Re: Smashing the Stack: prevention?, (continued)
- Re: Smashing the Stack: prevention? Thomas H. Ptacek (Apr 27)
- Re: Smashing the Stack: prevention? Russell Coker (Apr 28)
- Possibly exploitable buffer overflow in Solaris 2.5.1 ps Joe Zbiciak (Apr 28)
- Re: Possibly exploitable buffer overflow in Solaris 2.5.1 ps Geoffrey KEATING (Apr 29)
- Digital UNIX/Irix mesg problem Tom Leffingwell (Apr 29)
- Re: Digital UNIX/Irix mesg problem John Sheehy (Apr 29)
- Access control on W3C httpd server Peter Lord (Apr 30)
- vulnerabilities in kerberos David Sacerdote (Apr 29)
- Sun Security Bulletin #00139 Sun Security Coordination Team (Apr 29)
- SMASHING THE STACK: PREVENTION? massimo at vnet.ibm.com (Apr 28)
- Re: SMASHING THE STACK: PREVENTION? Alex Belits (Apr 28)
- Re: SMASHING THE STACK: PREVENTION? Thomas H. Ptacek (Apr 29)
- Re: Smashing the Stack: prevention? Thomas H. Ptacek (Apr 27)
- Re: Smashing the Stack: prevention? Tim Newsham (Apr 27)
- Re: Smashing the Stack: prevention? Joe Zbiciak (Apr 28)
- Re: Smashing the Stack: prevention? Daniel Ryde (Apr 28)
- xlock clarification.... David Hedley (Apr 28)
- Re: Smashing the Stack: prevention? Steve Coleman - SEWP (Apr 28)
- Re: Smashing the Stack: prevention? Alexander Snarskii (Apr 28)
- Re: Smashing the Stack: prevention? Michael Shields (Apr 28)
- Re: Smashing the Stack: prevention? Theo de Raadt (Apr 28)
- Re: Smashing the Stack: prevention? Shawn Instenes (Apr 29)