| |||||||||||||
|
| |||||||||||||
Open Source And VirusesOpen Source And VirusesPosted Jun 5, 2004 23:52 UTC (Sat) by flewellyn (subscriber, #5047)In reply to: Open Source And Viruses by eru Parent article: Open Source And Viruses A non-executable stack is basically a guard against buffer overflows. If you have, say, a language that does not allow such, by doing bounds checking, then that problem is eliminated. Another problem with non-executable stacks is that some languages, like Scheme and Common Lisp, actually need the stack to be executable. Of course, those languages do bounds checking anyway...
(Log in to post comments)
Open Source And Viruses Posted Jun 6, 2004 9:35 UTC (Sun) by eru (subscriber, #2753) [Link] A non-executable stack is basically a guard against buffer overflows. If you have, say, a language that does not allow such, by doing bounds checking, then that problem is eliminated.True but irrelevant. In the real world, most software in use will continue to be written in unsafe languages (and safe languages run in "nocheck" mode, and mixtures of safe languages and unsafe languages) for the foreseeable future. Besides, making a system secure needs "defense in depth": multiple barriers against exploits that are in theory redundant, but in practice aren't, because the implementation of each barrier is not perfect. Another problem with non-executable stacks is that some languages, like Scheme and Common Lisp, actually need the stack to be executable. Of course, those languages do bounds checking anyway... Efficient implementations of those languages (and of Java as well) do indeed generate code on the fly, but that code is placed on the heap, not on stack. An operating system that tries to make data areas non-executable must of course provide some controlled method to convert writable data memory into executable read-only memory, otherwise it cannot support language implementations that use such "just in time" compiling.
|
|
||||||||||||