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?

Comments

RISCy

[FidelCatsro]

If windows Ran on a RISC arch then it would be just as insecure .
The fact is not that this issue is an insecurity in X86 but the fact that windows uses it .If you know of a flaw in your architecutre then why are you programing
to that flaw .

Re:RISCy

[nocomment]

Bingo. Well said. OpenBSD runs on x86, does it have this flaw?

Re:RISCy

[Michalson]

Microsoft isn't the one relying on it, they just are supporting it to a degree because they understand the marketing importance of having backwards compatiblity for all the stuff people use (from a Joe user/Bob Company perspective, what's the point of "upgrading" to the latest version if suddenly your software/hardware stops working). Microsoft actually has got a lot of flak for making things tighter; a big one being the 9X->NT path that made a lot of API calls do a better job of checking parameters, resulting in sloppy programs being broken. More recently the SP2 update broke programs that mess with memory like a virus/exploit. So make up your mind - are they bad for maintaining backward compatiblity that is less secure/less stable, or are they bad for tightening things up and thus breaking a few badly written 3rd party programs people rely on.

Is this the Astrodome?

[winkydink]

2 articles in under 4 hours submitted by an "anonymous reader" that point to Paul Murphy at CIO Today. Hmmmm... Astroturf anybody?

Funny...

[scovetta]

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...

This guy doesn't know what he's talking about.

[ArbitraryConstant]

For starters, Windows does run on RISC.

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.

PowerPC doesn't offer more per-page protection than x86, and it offers less than x86-64, as x86-64 can disable execution on a per-page basis.

It's possible to do things on both architechtures like add a random offset to the stack or load libraries at random locations. This makes attacks much more difficult, and OSes like OpenBSD do them on both architechtures. OSes like Linux or MacOS don't do them on any architechtures. Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.

The mainstream architechtures of today do very little to distinguish themselves from each other security wise. One of the the few features that is different from one architechture to another, per-page execute protection, is not available on PowerPC.

This guy doesn't know what he's talking about.

Re:This guy doesn't know what he's talking about.

[pammon]

> 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.

Re:Stack

[pclminion]

A stack overflow ought to overwrite unallocated space, not earlier stack frames and return addresses. It's totally insane.

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.

Not so...

[dhowells]

Althought the insecurity of code that is only 'theoretically' exploitable ought to be fixed (we all prefer bug free code, right?) many theoretical exploits will never be practically exploited for technical reasons.

There is a distinction here which needs to be made between code which is exploitable but for which no public exploit code or method has been released -- in which cases it 'wont stay that way for ever' -- and code wherein the calculation of an arbitrary or runtime offset (e.g for a buffer overflow) is impossible and guesswork is impractically unlikely. Theoretical insecurities of the latter type are very likely to 'stay that way for ever'