mailing list archives
Re: Smashing the Stack: prevention?
From: jzbiciak () MICRO TI COM (Joe Zbiciak)
Date: Mon, 28 Apr 1997 02:14:47 -0500
|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
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
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.
|- - - - - jzbiciak () micro ti com - - - - -|
| - - http://ee1.bradley.edu/~im14u2c/ - - | Not your average "Joe."
|- - - - Texas Instruments, Dallas - - - -|
SMASHING THE STACK: PREVENTION? massimo at vnet.ibm.com (Apr 28)
Re: Smashing the Stack: prevention? Tim Newsham (Apr 28)
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? Shawn Instenes (Apr 29)
Re: Smashing the Stack: prevention? J.R.Valverde (Apr 28)
Re: Smashing the Stack: prevention? Randal Schwartz (Apr 28)