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

PR as Journalism (not)

[rossifer]

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

Re:PR as Journalism (not)

[ErikTheRed]

Something about news articles in general (as I learned from one of my clients, a PR agency) - many "reporters" create "stories" by basically doing some light editing (if that) on a press release. If you want to get your product or service in a newspaper, magazine, etc., the best thing to do is to have a pre-written piece that the "reporter" can slap their name on. It's a reasonable bet, for instance, that any positive story in your local paper about some local business was written either by that business or their PR agency. That doesn't necessarily mean it contains untrue information, but it certainly colors whatever facts are included.

This is the actual main reason for many people's complaints that news sources lean too far left or right or whatever - much of the "news" is generated by PR firms, advocacy groups, political parties, etc., given a very thin coat of paint, and slapped on the page. Some actual work is done on the editorial page, and in the reviews (although there have been some "reviews" done along these lines for things like restaurants - caveat emptor), but by and large you should take most newspaper and magazine stories with an appropriate grain of salt (unless you have a particularly high level of confidence in a specific writer or publication).

Happy Paul Murphy Day

[Anonymous Coward]

What, is there only one tech writer in the world? (See article two or three down on SCO)

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?

I gotta call bullshit on this one...

[HotNeedleOfInquiry]

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.

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

Stack

[Sloppy]

The x86 has always been known to be inferior. But the most blatant problem isn't lack of execution permission bits by page, or anything subtle. The biggest problem is something so huge and obvious, that people have stopped being able to see it, because they're completely immersed in it.

On x86, the stack grows backwards. Backwards! A stack overflow ought to overwrite unallocated space, not earlier stack frames and return addresses. It's totally insane.

But I guess when you live with insanity year after year, you get used it.

Re:Stack

[CajunArson]

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.

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.

Re:Stack

[leshert]

But why I ask is the OS allowing one process to overwrite memory of another.

It doesn't--that's not what an overflow attack is.

An overflow attack causes a process to overwrite its _own_ memory, with instructions carefully chosen by the attacker. The attacker's code is executed by the attacked process itself.

Think of it like the old Bart Simpson gag of calling up Moe's and asking for "Mr. Butz, first name Seymour". If you can get Moe (the process under attack) to repeat what you say (the attack payload), he's as good as yours.

RISC isn't the solution

[ikewillis]

I administrate dozens of Solaris/SPARC systems over the years. While implementing a buffer overflow on this architecture may be less trivial, I can't tell you how many buffer overrun patches I've installed over the years in various patch clusters.

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.

1993 called - they want their flamewar back

[nosferatu-man]

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

Not the fault of the OS at all!

[carcosa30]

SO! We now know the truth: Microsoft is blameless for the shoddy security of their products. It's all the fault of the x86 architecture.

After all, how could Microsoft be expected to learn the intricacies of their primary platform and write code that does what it's supposed to?

We have been lied to.

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.

I doubt x86 inherently flawed

[rice_burners_suck]

In all, I don't think the processor is really responsible for most of these problems. I think it is the design and implementation of software. Things simply must be done correctly, or computers will go haywire no matter what kind of processor they have.

Linux, BSD, and other *nix systems are reasonably well protected through the design of the system and the widespread use of common server programs, which are checked and re-checked for these problems by a variety of people and organizations. Also, GCC provides ProPolice, which can help lock things down a bit more. I think this particular problem mostly applies to systems running Windows.

Microsoft's business problem in this regard is that they have no control over the applications running in Windows, and they provide a default Windows install that is quite open and vulnerable. Locking down the ports and getting rid of the most dain-bramaged policies in Windows is only one part of the solution. Vulnerabilities in application programs can still be used to break into these systems, and Microsoft will ultimately be blamed.

Perhaps the best thing Microsoft can do is integrate something like ProPolice into the C and C++ libraries used to compile programs for Windows. This would make a big difference in protecting the stack of running programs that are not designed with security as a priority.

If x86 really is less secure by nature, it probably wouldn't hurt if they'd put their virtualization engine (similar in function to VMware but not even half as good) right into the core OS. Under such a design, only the Windows kernel would run directly on the processor; the rest of the operating system and all of the application programs would run with the same x86 instruction set, but through the virtualization engine. There, checks could be made to prevent the most common vulnerabilities of the x86 processor from being utilized.

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'

Bollocks!

[EmbeddedJanitor]

On many/most RISC you can grow the stack in any direction. By convention, most ARM code runs a down-growing stack,

The stack direction has nothing to do with security. You can still have stack protection running up or down stacks. Once you have a reasonable MMU, all further problems are due to software design.

PowerPC doesn't prevent buffer overflow exploits

[Branka96]

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

Media Watch

[xixax]

Our public broadcaster has a show calledMedia Watch that routinely busts journalists for plagiarising press releases. Not to mention even more forward things like running advrtisements as news.

Xix.

These "insecurities" not only limited to CPU type.

[Anonymous Coward]

Every once in a while there is somebody who claims a certain CPU type, operating system, etc. is more secure simply by its basic structuring. The main point made here is that x86 is less secure because of its process memory layout. Lets take a look at a few known and popular high impact vulnerabilities and examine the reasons why they could be exploited:

• The telnetd AYT heap overflow (2002) could be exploited on x86/*BSD systems specifically because of their memory layout and little-endianess, while MIPS and SPARC systems were saved by their big-endian, 64bit addresses. Yet, on x86/Linux it was not exploitable, because of a different memory layout within the heap.
• The Solaris login heap overflow (2001) could be exploited on both x86 and SPARC. The reason were that addresses are created by the vulnerable code itself.
• The SSH1 CRC32 overflow (2000), has been exploited on every known architecture, x86, SPARC, MIPS, etc. because the data used to overwrite memory with were created by the vulnerable code itself, hence endianess and order did not matter.

Now, there are cases where RISC architecture makes exploitation more difficult to impossible. But there are around an equal amount of cases where x86 is saved. But the reason is not to be found within the architecture alone, but within differences in the whole chain from CPU to process memory layout to ABI and runtime environment. The following are especially important to determine if a vulnerability could be exploited on a given system:

• CPU, word width and endianess
• process address layout
• stack frame handling and layout, how registers are saved (register windows?) order of registers/parameters/locals/alloca
• heap handling (i.e. what malloc allocation system is used. For example, most *BSD systems use an out-of-chunk management to control the heap structure itself, while glibc uses an inband management, which is by nature more likely to allow exploitation)
• compiler optimizations, eg. if small functions are inlined omitting stack frames, etc.
• ...

Speaking with more than eight years of exploit development experience, there is much more to consider than just the CPU type.

The problem is C, not the hardware

[Animats]

It's certainly possible to build machines which prevent buffer overflows. Burroughs did that from 1958 to about 1990, quite successfully. Every array is in its own segment. Memory addresses aren't numbers; they're a sequence of descriptors, more like a pathname than a pointer. The last element of the pathname is the array subscript. A descriptor that goes off the end of an array generates a subscript-out-of-range exception.

But it's tough to run C on that kind of architecture. C wants pointers to be addresses. The "array is a pointer" convention is a bad fit to a true segmented architecture. You can run Pascal just fine, but running C is tough. It can be done, but basically requires allocating all the variables in one big "array" at the hardware level, so you lose the protection. When C came in, the Burroughs machines (by then the Unisys A series) died off.

So it's quite possible to fix this, but you have to dump C. This may happen as Java and C# get more traction.

C++ doesn't help. It's part of the problem.

Dissemination of this information is encouraged

[44BSD]

http://cvs.openbsd.org/papers/auug04/

Theo talks about how OpenBSD uses various available processor features to increase system attack resilience, w/minimal performance impact. The design choices made for architectures with differing degrees of per-page protection are presented. The concepts are not at all OpenBSD-specific, although the implementation discussed is, of course, OpenBSD.