Technocrat.net: Are buffer-overflow security exploits really Intel and OS makers fault?Jul 29, 2000, 15:04 (13 Talkback[s])
(Other stories by Bruce Perens)
[ Thanks to Bruce Perens for this link. ]
Update: The story has been pulled with the
"Buffer-overflow security exploits are common, but your computer shouldn't really be vulnerable to them. It seems the main problem is with the i386 architecture. Secondary to that, there's the problem of operating systems that could protect against this sort of exploit by using a simple facility of the virtual memory hardware, but don't."
"On processors with an execute-protect bit on their VM pages and an operating system that uses it properly, buffer-overflow security bugs can never introduce new executable code into a process. We can make this facility available in operating systems like Linux as users transition to processors like Intel's new ia-64 architecture (also known as Merced or Itanium) and the ALPHA and MIPS chips. I don't think any of these chips have any reason to need the execute bit turned on for stack or data pages. Rare programs that actually run self-modifying code, like Java just-in-time compilers and programs that use executable "trampoline" code on the stack would have to turn off this protection, but that should be done selectively, on a page-by-page basis. Linux already has a system call, mprotect(), to do that."
"I'm told that someone named "Solar Designer" actually produced a patch to do this for Linux, but that Linus hasn't accepted the patch into the main kernel source. Apparently, there's even a way to make it work on the i386, for the stack but not data regions, by using segmentation instead of paging. I can see why that would inspire Linus' esthetic revulsion, even though it's an important security fix. Also, someone showed one way to defeat the patch, but a good many exploits would be stopped dead. The people on the Linux kernel list, I'm told, have discussed and rejected this idea twice now. Maybe it's time for the rest of us to take it more seriously. There's also the StackGuard Compiler, which hardens code against stack attacks and can detect them. We need both of these tools in our systems."
0 Talkback[s] (click to add your comment)