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?
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...
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.
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.
Check Raymond Chen http://blogs.msdn.com/oldnewthing/archive/2004/09/ 14/229387.aspx
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!
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.
Engineering is the art of compromise.
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.
> But why I ask is the OS allowing one process to
...does...stuff...here...
:-(
> 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.
Actually, most of the ia32 nastyness is there for backwards compatibility.
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.
/. is good for you.
Xix.
"Everything is adjustable, provided you have the right tools"
Well, yes, in the sense that 25 is more than 15.
The 8086 (and its lesser brother the 8088)came out in 1980, IIRC.
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.
You'll tend to see rewritten press releases in the business section. The front page of most newspapers originates in wire service articles: AP, Reuters, AFP, sometimes big national papers like the Washington Post or the New York Times.
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.
My 8086 processor is stamped 1978.
This got +5? Mods don't know what they are reading about.
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.
The Catholic Church counts some 1.1 billion members, give or take, so about the size of China, or perhaps a little less. Islam is the second-largest religion with about 850 million adherents, though this does not include sects such as Sunni and Shi'ite, which the Catholic Church basically is.
You can never go home again... but I guess you can shop there.
Sunni and Shi'ite sects make up the significant majority of Muslims, but there are other sects. I know of the Druze, Alawi, and Ismali (Ismaeli?), but there are others, though even combined they are a very small percentage of the overall religion.
You can never go home again... but I guess you can shop there.