On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote:
OK, I hate to flog a dead horse but really:
Hmmmm, this is likely to start a looooong drawn out flame thread. Language arguments almost always do. So, with trying to prevent that in mind, I will avoid standing up for my general language of choice and instead offer an alternative.
This exploit, like others against Unix machines many years ago, was based on a buffer overflow dumping the user into supervisor space. This, in turn, is a direct result of the fact that the C programming language does not check or enforce limits on a string length or buffer size - that's left up to the individual programmer.
Surely, given the importance of security, it should be possible to fix the C language (or my preference, use a different one) to do systems programming. After all, C is not so much a systems programming language as a high-level version of assembly language.
"Fixing" C in the sense you're imagining will never happen and people often do use other languages for specific tasks. However, other languages are not immune to buffer overflows as most of them are actually written in C themselves. The better solution is things like stackguard[1] and execshield[2] which actually fix the root problem: the stack should NOT be executable and neither should most of the heap and likewise portions of memory which are actively executable shouldn't be writable from userspace.
(Incidentally, a former profs at Ryerson, Heather Hinton, was working on such a mechanism to prevent stack overflows. I guess it's never been widely adopted.)
Hinton...any relation to Geoffrey Hinton? At any rate, many people have (and continue) to work on stack guards and similar solutions. See [1] and [2]. As with all security measures, its just a question of getting people to use them. -- Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> [1] http://www.immunix.org/stackguard.html [2] http://seclists.org/lists/linux-kernel/2003/May/0371.html and http://people.redhat.com/mingo/exec-shield/ -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml