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>--------+