Slashdot Mirror
Is the x86 Architecture Less Secure?
An anonymous reader asks: "Paul Murphy at CIO Today reports that a specific Windows buffer overflow vulnerability ' depends on the rigid stack-order execution and limited page protection inherent in the x86 architecture. If Windows ran on Risc, that vulnerability would still exist, but it would be a non-issue because the exploit opportunity would be more theoretical than practical.' And implies that other Windows vulnerabilities are actually facilitated by having an x86 chip." How does the x86 processor compare with other architectures when it comes to processor based vulnerabilities? How well have newer additions, like the Execute Disable Bit, helped in practical situations?
Paul Murphy, I'd like you to meet Paul Graham. What we have here is an Apple press release being printed up as a trade journal article.
Good for Apple's PR firm. I guess.
Not that I have anything against Macs or PowerPC hardware, I just don't like disengenuous authors (or their articles).
Regards,
Ross
What, is there only one tech writer in the world? (See article two or three down on SCO)
If windows Ran on a RISC arch then it would be just as insecure . .If you know of a flaw in your architecutre then why are you programing
The fact is not that this issue is an insecurity in X86 but the fact that windows uses it
to that flaw .
The only things certain in war are Propaganda and Death. You can never be sure which is which though
2 articles in under 4 hours submitted by an "anonymous reader" that point to Paul Murphy at CIO Today. Hmmmm... Astroturf anybody?
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Blame the machine or blame the programmer? You can write x86 code without buffer overflows, period. That you can be more sloppy on other architectures and not get overflows seems silly. Like "everyone should drive Volvos cause they are safer."
Lots of things can be laid at the feet of x86 architecture, but not that it seduces programmers into writing code with buffer overflows.
"Eve of Destruction", it's not just for old hippies anymore...
If Windows ran on Risc, that vulnerability would still exist, but it would be a non-issue because the exploit opportunity would be more theoretical than practical.
Funny how exploits that are "just theoretical" don't stay that way forever...
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
The real disadvantage of x86 over a RISC architecture like SPARC is that it doesn't have page protections (not to be confused with real mode segmentation which essentially disables the protected mode i386 MMU) where pages containing data and code are marked differently, so data pages are non-executable. sparcv9 implements a non-executable user stack per default, whereas it's a configurable option for sparcv8 binaries.
This has all changed with x86-64/AMD64/EM64T/x64/WHATEVER, which has brought a noexec bit to memory pages and allows hardware buffer overflow protection similar to SPARC. This still isn't a silver bullet for buffer overflows, but it's certainly better than nothing.
Thanks, Slashdot -- I actually read that boatload of ignorant gibberish, and now I'm measurably dumber than I was before I clicked the link. Keep this up and I too will be making specious arguments about "RISC" and "CISC".
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Bzzztt.... wrong, Thankyou for playing. As I learned firsthand when coding buffer overflows in a security class, it is a simple, easy, and wrong assumption to think that the stack growing down is the main reason you can do buffer overflows. The main reason is that you are allowed to write where you're not supposed to, not matter what direction the stack grows. Hint: Remember what a stack is exactly... a buffer overflow can just as easily write up into another function's space and execute the overflow from there.
It actually turns out that a bunch of the random relocation and offset tricks while helpful, can still be defeated, so simply growing the stack in a different direction is not a real solution.
AntiFA: An abbreviation for Anti First Amendment.
Not really. You assume that all buffer overflows overflow in the "upward" direction. It's just as easy, in C, to code a loop that progresses backward through memory. I've had many reasons and occassions to do it. Simply making the stack grow upward instead of downward won't solve the underlying basic issue, which is that without proper bounds checking, the program can overwrite memory it's not supposed to.
Besides, it's incredibly convenient for the stack to grow downward. Program code and data starts at the bottom of virtual memory, and the stack starts at the top. You just map in new page frames as necessary. If the stack grew the other direction, it would either have to be limited in size, or you'd have to shift it in memory if it grew too large. Shifting it is practically impossible, since you'd have to find all program pointers into the stack and update them all to reflect the new stack. Gad, I don't even want to think about it.
CAN-2004-1134 is a buffer overflow issue. The Mac is susceptible to buffer overflows.
Take e.g. the iSync issue. Apple doesn't go into details, but if you do a Google search on "isync vulnerability" you will find:
"The vulnerability is caused due to a boundary error in the handling of the "-v" and "-a" command line options. This can be exploited to cause a buffer overflow by supplying an overly long argument (over 4096 bytes). Successful exploitation allows execution of arbitrary code with the privileges of the mRouter application."
A proof of concept exploit can be found at. It opens a root shell.
When the PowerPC jumps to a subroutine, the return address is stored in the lr register. The first thing the prolog code in the subroutine does, is to put the address on the stack (freeing up the register for further function calls). So, a would-be hacker can overwrite the return address. For a description of how to take advantage of buffer overflows on the Mac, see "Smashing The Mac For Fun & Profit".
> The stack behaviour of PowerPC is just as
> predictable as x86, and it's just as easy to
> perform a buffer overflow attack on vulnerable
> code.
No it's not.
For example, here's a function vulnerable to a classic buffer overflow:
void security_hole(char* s) {
char buff[128], *ptr = buff;
while (*s++ = *buff++);
}
It's more difficult to turn this buffer overflow into arbitrary code execution on PowerPC because the link register isn't spilled to the stack (so you have to overwrite some function's return address higher up in the call chain) which takes more work and requires a larger payload, larger instruction sizes means you need a still larger payload, larger instruction sizes mean it's trickier to build an instruction stream with no zero bytes, and in any case you may have to flush the instruction cache to force it to see your changes - no easy task.
Leaf functions, functions that take advantage of tail-call optimizations, and functions that move the link register into a GPR rather than the stack don't let you overwrite the return address at all, which is never the case on x86.