One issue with buffer overrun protection is that it may break some old
software. But that may be software you don't want to
run in the first place.
I think the Sparc CPUs had that feature all along.
In general, BSD and (patched) Linux kernels had various protections like
this.
For example, these patches will allow you to make the stack
non-executable. This will prevent the popular stack overflow
exploits. You can still overflow the stack, but it will likely
just crash the program, as you can't execute the code you wrote.
To protect against heap overflows, these systems allow you to
mark certain memory areas as 'non executable'. For example, this is the
memory you write the data into.
Both of these systems do not require any changes to existing
applications (unless they violate any of these rules, which can happen).
The most recent RedHat 9 glib update for example marked one piece of
executable code as data, and as a result a lot of grsecrity/PaX patched
machines stopped working :-(
The other option is to compile applications with various protection
mechanisms. In this case, only this particular application is protected.
E.g. if there should be a buffer overflow, the special libraries its
compiled with will protect it. The advantage in this case is that
existing programs will not be effected (some people may see this as a
disadvantage).
--
CTO SANS Internet Storm Center http://isc.sans.org
phone: (617) 837 2807 jullrich at sans.org
contact details: http://johannes.homepc.org/contact.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.dshield.org/pipermail/list/attachments/20040109/1affc2d8/attachment.bin