Bugtraq mailing list archives
Re: Smashing the Stack: prevention?
From: jzbiciak () MICRO TI COM (Joe Zbiciak)
Date: Mon, 28 Apr 1997 02:14:47 -0500
|In reading |the above mentioned articles, this list, and scowering every dark corner |of the net, I have put together a few different methods folks are using |to fight the buffer overflow problem, i'm looking for everyone's input |and ideas for solutions to the buffer overflow problem.. Although, as Mr. Ptacek points out, these are just plugging the holes in a bursting dike, I think the approaches you mention are valuable as a stopgap. One possible solution I've considered is patching the kernel to trim all argv/envp strings to a specified length if the program being exec'd has the suid/sgid bit set (or alternately, just impose a tighter system- wide limit on a 'critical' machine). This shouldn't be too difficult to implement, and should catch the majority of buffer overflows. This *won't* catch buffer overflows that are exploited over a data stream (ie. akin to the fingerd overflow that the infamous Internet Worm exploited eons ago). Ironically, published descriptions of said worm a year and more ago described that sort of exploit as "arcane", and "difficult to implement" and as requiring an intimate knowledge of the program and the hardware involved. Now we have fairly generic buffer-overflow-exploit frameworks that are adapted almost trivially and automatically whenever a buffer exploit is found. As pointed out elsewhere, these approaches don't solve the problem. While it's been argued that there is too much privileged code, I'm not convinced that that's entirely the problem. The problem is *why* that code is made privileged to begin with. Standard Unix privileges are pretty much all-or-nothing; you're either the superuser or not. Granted, Unix filesystem permission semantics get you some of the necessary granularity, but far too many tasks are thrown in the superuser bucket. Still, this last argument doesn't address the security concerns surrounding other exploits, such as a buffer overflow in a webserver which allows remote users to run arbitrary commands on a website. It doesn't matter what priv. level the webserver is running at; so long as the webserver can fork a shell or similar, the intruder is able to get quite far into the machine without special privleges beyond what's afforded to a mortal user. Same with fingerd, or any other number of services which may be exploited remotely, and which are likely not running with special permissions. For these cases, the bounds-checking and removing the stack-execute-bit are very helpful as a safety-net. --Joe -- +--------------Joseph Zbiciak--------------+ |- - - - - jzbiciak () micro ti com - - - - -| | - - http://ee1.bradley.edu/~im14u2c/ - - | Not your average "Joe." |- - - - Texas Instruments, Dallas - - - -| +-------#include <std_disclaimer.h>--------+
Current thread:
- Re: Possibly exploitable buffer overflow in Solaris 2.5.1 ps, (continued)
- 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? 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)
- Re: Smashing the Stack: prevention? J.R.Valverde (Apr 28)
- Re: Smashing the Stack: prevention? Randal Schwartz (Apr 28)
- Re: Smashing the Stack: prevention? Thomas H. Ptacek (Apr 29)