Is the x86 Architecture Less Secure? 315
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?
I gotta call bullshit on this one... (Score:5, Informative)
Lots of things can be laid at the feet of x86 architecture, but not that it seduces programmers into writing code with buffer overflows.
RISC isn't the solution (Score:5, Informative)
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.
I doubt x86 inherently flawed (Score:5, Informative)
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.
Re:RISC isn't the solution (Score:3, Informative)
Old New Thing (Score:2, Informative)
Alternative. (Score:1, Informative)
If you are a bit curious why most C compilers don't do this as well. It is possible on x86 to use the stack pointer only for return addresses and then some other register to point to a "value stack" in some other disjoint area of memory. Not only would this make it easier on debuggers (crawling backwards from the current stack frame) but also lessen the impact of a typical return address remote code execution style buffer overflow.
However there is a down side to this, on x86 there are so few registers that to have two stack pointers is going to make code way more ineffeicient (many more spills to and from the stack). At least x86-64 doesn't have this problem, so there is one side of the "suckitude" of x86 right there (but hey, the string instructions are nifty data movers, I wish other CPU's had them at x86 speed).
So there are some architectural issues in x86 that are inherently bad when it comes to security. Then there are features that are inherently good but hard to use (segment registers, descriptor tables, and the "onion ring" enforced HW security).
The issue with stacks growing upwards (and heaps growing downwards) is pretty true. Having a stack growing downwards is a bit less secure because buffers tend to grow upwards in memory. Accessing past the end of an array is a much more common bug than accessing too low. Although its amazing how simple data validation failures can result in some interesting addresses being generated.
Disclaimer: I am a low-level snobb who writes code in assembly and C that has to have microsecond-accurate performance on old Motorola 68k's, so telling me to use java or some other interpreted high level language where the runtime footprint is larger than the amount of RAM I have to work with ain't gonna cut it. It may work for business apps but not embedded systems!
Bollocks! (Score:5, Informative)
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.
Re:Stack (Score:5, Informative)
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.
Re:Stack (Score:2, Informative)
> overwrite memory of another.
It's not allowing a process to directly overwrite another process's memory. Buffer overflows basically "trick" a program into overwriting bits of its own memory that the author didn't expect.
> Is it just that the stack is limited?
It's something that you have to code carefully to avoid, since C lacks various checks that avoid the programmer having to worry about this. Lots of languages do have these checks but they're less popular.
Stacks on x86 grow downwards (i.e. to lower memory addresses). Each time you call a function, the top of the stack gets *lower* in virtual memory.
Suppose we have a function "foo":
void foo()
{
char[12] filename;
return;
}
It allocates a 12 character array *on the stack*. If we can trick foo() into writing more than 12 characters into the "filename" array, then it'll continue to write the data into higher and higher addresses *overwriting earlier data on the stack*.
The process is overwriting its own memory so there's nothing the OS can do to protect against it. The trouble is that if the data foo() read is not only too large but contains some malicious code, the application may be tricked into running that code when the function exits. If the application was running as root (or if the code was part of the kernel) then that malicious code now has control of your system
> As another posted said is it a hangover from
> days of tightly limited system resources
> and no swap?
Not really, it's something that just happens. Writing code which allows buffers to be overflowed in this way is sloppy - the coder got it wrong.
Re:News Flash! x86 sucks! Film at 11! (Score:1, Informative)
A20, real mode, virtual 86 mode, system management mode, real mode BIOS interface, partition table format, boot block limitations, etc. can be eliminated flat out if desired. Intel even sells some embedded ia32 processors that have no real mode support, they start in protected mode.
No, the real problem is the lack of end-of-life phasing out of junk that isn't needed anymore. Most of this stuff simply isn't needed today, and can be emulated if needed.
Re:RISCy (Score:2, Informative)
Media Watch (Score:5, Informative)
Xix.
Re:How Long? (Score:1, Informative)
The 8086 (and its lesser brother the 8088)came out in 1980, IIRC.
Re:Stack (Score:1, Informative)
Dissemination of this information is encouraged (Score:5, Informative)
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.
And wire services... (Score:3, Informative)
If you click through a news story from a news aggregator like Google News, you'll note that many of them have identical text, because they're literally repeating the AP wire service story, crediting the original AP writer and all.
Actual reporters are used primarily for local news; very few newspapers have staff anywhere else. Most don't even have reporters in Washington, much less Paris/Jakarta/Darfur.
The bias comes not so much from the writers as from the editorial choices of which press releases and wire reports they're running and what page they put them on.
Either way, they rarely get the skeptical eye you'd really hope they get before receiving the imprimatur of being printed in the newspaper. Even a few phone calls would be nice.
Re:How Long? (Score:1, Informative)
Re:I doubt x86 inherently flawed (Score:2, Informative)
Buffer overruns are caused purely by sloppy coding in languages which let you. They exist on all CPUs, but they are easier to exploit on x86 due to the orientation of the stack (placing the return address of a function at the end of the stack) and lack of memory security options (until x86-64 introduced the NX bit all memory is executable.)
Buffer overruns are incredibly common problems and plague all development. Debian has announced 33 buffer overrun vulnerabilities in their distribution so far for 2005. All it takes is one. The architecture is only relevant insofar as to the amount of damage that can be performed once the binary has been exploited, and would be just as contained on a properly administrated Windows computer as on a properly administrated Linux computer.
Microsoft has been working on this issue fairly diligently. For the past three years their C++ compilers have included buffer overrun protection by placing code in the prologue of the function to save the return address in a "cookie" and then validate the return address in the epilogue with that "cookie" to ensure that it has not changed. This will catch the more common errors which account for easily 90% of all buffer overruns. All code produced by Microsoft since has been compiled with this option. Microsoft has issued several code libraries which provide bounds checking for buffers to aid the developer in avoiding these problems. Microsoft has added DEP to Windows XP SP2 and Windows 2003 SP1 which are a software attempt, in kernel mode, to catch buffer overruns. And finally, Microsoft has added support for the NX bit in the x86-64, which is the only way for the CPU to enforce that data pages be non-executable. Unfortunately this last method is the only method through which this problem can be fully mitigated.
Re:This guy doesn't know what he's talking about. (Score:2, Informative)
PowerPC does not store the return address on the stack; it shows up in the link register (LR), and is generally copied to a GPR when your function calls another function (because the call will overwrite the LR). That GPR may or may not wind up on the stack, depending on the number of GPRs needed by the callee. The architecture does not require that it ever be placed on the stack, which is totally defined by the ABI and not by the hardware anyway. There is absolutely no reason why PowerPC-based operating systems could not define a separate stack for data and return addresses, if the OS designers chose to do so.
Re: Biased (not) (Score:3, Informative)
Re: Biased (not) (Score:3, Informative)