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?
thats because (Score:3, Funny)
stopping buffer overflows. A how to. (Score:2, Interesting)
Or some good programming practices. [ibm.com]
PR as Journalism (not) (Score:5, Interesting)
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) (Score:3, Interesting)
Re:PR as Journalism (not) (Score:5, Interesting)
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).
Re:PR as Journalism (not) (Score:2)
Writers are people. People are lazy. Small wonder PR firms are smart enough to exploit it...
Media Watch (Score:5, Informative)
Xix.
Re:Media Watch (Score:3, Insightful)
What's the point of a balanced press release?
If you're not pumping your "side", you're not doing a good job.
Re: Biased (not) (Score:3, Insightful)
about Michael Jackson, Mrs. Stuart, and the Pope.
This is what is passed as "news". Is the
media biased towards the left or towards the
right? When all they do is talk about
the unimportant, the media is not biased at
all! They are just silly.
Re: Biased (not) (Score:3, Informative)
Re: Biased (not) (Score:3, Informative)
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
Happy Paul Murphy Day (Score:5, Funny)
RISCy (Score:5, Insightful)
The fact is not that this issue is an insecurity in X86 but the fact that windows uses it
to that flaw .
Re:RISCy (Score:5, Insightful)
Re:RISCy (Score:4, Interesting)
Re:RISCy (Score:3, Interesting)
The security advantage of MacOS X is a lack of braindead design decisions, it has nothing to do with PowerPC.
Real Solution -- Signetics Write Only Memory! (Score:2)
Better yet, you can use the Signetics chips in both PCs *AND* Macs!
ttyl
Farrell
Re:RISCy (Score:5, Insightful)
Is this the Astrodome? (Score:5, Insightful)
Re:Is this the Astrodome? (Score:2)
This issue itself is intresting though . Though i am fairly sure it was discussed a couple of years back when AMD introduced the non executable area in the Athlon and opteron chips
Re:Is this the Astrodome? (Score:3, Funny)
Right this instant, I'm working on my "Windows better for pirating media files" opinion piece. It's a surefire winner.
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.
Re:I gotta call bullshit on this one... (Score:2, Insightful)
Blame the machine or blame the programmer?
How about blaming both?
A machine can make it more difficult for extremely common types of attack to be successful. If it doesn't, then it shares some of the blame.
A programmer can avoid troublesome functions and coding styles, can test with bad data more thoroughly, and can use automated tools to catch these problems before they are a security issue. If they don't, then they share some of the blame.
A programming language can mitigate these issues by p
Re:I gotta call bullshit on this one... (Score:3, Insightful)
What the author of this article is saying is that PowerPC-based computers would only have a 1-in-6 chance of being able to execute code arbitrarily spilled over actual code via buffer overflow.
Moreover the way that data and code "segments" (I'm using the x86 word here) just don't work the same way on PowerPCs. This essentially prevents arbitrary
Re:I gotta call bullshit on this one... (Score:2, Interesting)
As for bugs, I agree with you but I also know how easy and how common it is. We need to use multiple tools, just saying hire better coders or something to th
Re:I gotta call bullshit on this one... (Score:2)
Re:Bad analogy (Score:3, Funny)
Yes, but only cdr analogies get +1, Funny.
Funny... (Score:5, Insightful)
Funny how exploits that are "just theoretical" don't stay that way forever...
Not so... (Score:4, Insightful)
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'
Re:Funny... (Score:2)
-Slak
Re:Funny... (Score:4, Interesting)
I always liked this phrack article about how to exploit an appearently unexploitable bug [phrack.org]. After reading this, I would be very cautious about clasifying a bug as unexploitable.
Stack (Score:4, Interesting)
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 (Score:2, Insightful)
Careful programming when dealing with memory in a language without builtin bounds checking is the solution to this problem.
Re:Stack (Score:5, Interesting)
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 (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'r
Re:Stack (Score:2)
It's not totally insane. The stack and data areas both grow into unallocated space. In a system without paging (such as the 8080, which the 386+ is ultimately decended from), this is the easiest to allocate. It only becomes a problem on stack overflow or memory exhaustion. It's also the way most architectures work. (at least the 8080, 8086, 80286, 80386+, 2502, 6800+, 68000+, VAX, etc, which is to say every architecture I've ever programmed in assembley). I have a PPC assembley book
Re:Stack (Score:2)
So if you cponsider this is a sign of CPU inferiority, well, I hope you're an HPUX fanboy.
Re:Stack (Score:5, Insightful)
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 (Score:2)
I mean, there were a lot of design decisions that made sense back in the day, but I'm always wondering if a fresh ground-up processor design might not have some advantages...
Re:Stack (Score:2)
why change something so level when so far it works
note, I'm not saying that it shouldn't be changed, but refactoring code is one of the most ignored aspects of software and hardware development simply because you gotta include backwards compatibility
Re:Stack (Score:4, Insightful)
0x00000000 isn't the math number 0, nor is 0xFFFFFFFF unless you assign that meaning to it. A perfect example is in floating point numbers, which mean something totally different that the same sized integer, which is totally different that the same sized memory address.
As others have already said. It's not the direction, it's the ability to do something that you shouldn't be able to do.
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:2, Insightful)
Well, some direction needs to be unallocated.
Hey, I can't say "bugs are ok." It's just a question of how catastrophic you want the bugs to be. Maybe having them always be a distaster (because return address gets overwritten) has some advantages, in that it makes bugs less subtle so the developer will more likely find them. But according to history, that seems to have not worked out, given that even non-programmers now know what
One correction... (Score:2)
The PPC architecture doesn't have a stack pointer register, or any dedicated "push" or "pop" instructions. The stack growth direction is an OS feature, not a processor feature.
-Mark
Re:Stack (Score:2)
-Mark
Maybe I'm missing something here... (Score:3)
Re:Maybe I'm missing something here... (Score:3, Insightful)
Re:Maybe I'm missing something here... (Score:2)
Re:Maybe I'm missing something here... (Score:2)
Re:Maybe I'm missing something here... (Score:2)
Re:Maybe I'm missing something here... (Score:2)
Riiight..
char a[5];
int b=-5;
printf("%x %x\n",&a,&a[b]);
It doesn't matter what direction a stack grows, you can access the entire stack.
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.
Re:RISC isn't the solution (Score:3, Informative)
Re:RISC isn't the solution (Score:2)
Re:RISC isn't the solution (Score:2)
Right now modern operating systems simply set the segmentation registers to have a base of 0 and a limit of the end of memory, thus creating one big segment. You could have segments as well as paging, but that would be a pain in the ass. Of course we now see the problem with fai
Re:Administrate isn't a word (Score:2)
void process_string( char *pstr )
{
char tempbuf[1024];
strncpy( tempbuf, pstr, 1023 );
buffer[strlen(buffer)-1] = '\0';
}
Re:Administrate isn't a word (Score:2)
void process_string( char *pstr )
{
char tempbuf[1024];
strncpy( tempbuf, pstr, 1023 );
tempbuf[strlen(tempbuf)-1] = '\0';
}
Re:Administrate isn't a word (Score:2)
Re:Administrate isn't a word (Score:3, Interesting)
Sometimes you have to do that, but I prefer instead to make sure that all uses of that buffer don't assume it is zero-terminated unless I can guarantee that it is.
Re:Administrate isn't a word (Score:2)
I don't think the problem is forgetting to terminate a char array so much as counting on the other guy to provide a pointer to a properly terminated array of the correct size.
Always gotta check your arguments for termination within the correct bounds...
Well... (Score:4, Funny)
Still here? Dammit...
big deal.. (Score:2, Funny)
Re:big deal.. (Score:2)
1993 called - they want their flamewar back (Score:5, Funny)
Re:1993 called - they want their flamewar back (Score:3, Insightful)
News Flash! x86 sucks! Film at 11! (Score:2)
Now really, we all know that x86 sucks noodle for various reasons (A20 anyone?), so why does it draw attention when somebody says it out loud? It wasn't so much designed, rather cobbled together with cludge upon cludge to retain backwards compatibility. It's all known!
Granted, if it kills x86 once and for all before yet another actually useable arch like Alpha is eradicated, it's not bad.
Not the fault of the OS at all! (Score:5, Funny)
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. (Score:5, Insightful)
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. (Score:2)
And no Linux distribution allows you to make use of your own compiler flags?
Re:This guy doesn't know what he's talking about. (Score:2)
Of course you can set your own compile flags. That would be why I said "Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.". You clipped that part of my sentence in your quote.
The other features I mentioned require OS support, as they involve small but significant changes to the internals of the OS.
Re:This guy doesn't know what he's talking about. (Score:3, Interesting)
Linux does [lwn.net] support limited stack and library randomization. However, there are questions [stanford.edu] as to the effectiveness of these techniques.
Re:This guy doesn't know what he's talking about. (Score:3, Interesting)
Probably. Dunno since I stopped RTFAs a while ago.
However, the IBM PowerPC 970FX aka Apple G5 processors have had NX for a while. Partial Linux support already exists. Check it out.
http://lwn.net/Articles/126862/ [lwn.net]
I like the 970FX (apart from its tiny cache). Shame Apple has a monopoly on the desktop systems, and you have to buy their OS to run Linux on one.
Re:This guy doesn't know what he's talking about. (Score:5, Insightful)
> 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 (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:I doubt x86 inherently flawed (Score:2)
Oneday we'll look at x86 like VHS to the DVD, or like magnetic tape cassettes to the mp3 player.
NX bit (Score:2, Interesting)
More theoretical than practical (Score:2)
Windows doesn't take advantage of the hardware (Score:2, Interesting)
Re:Windows doesn't take advantage of the hardware (Score:2)
Re:Windows doesn't take advantage of the hardware (Score:2)
A bunch of niche OSs that you've never heard of, including Flex/OS, CPM/386, Coherent, and probably a few others. A fair number of embedded systems use at least the segmented memory model to some advantage, either in a custom OS, or within the application itself.
-Mark
OpenBSD does (Score:2)
This is actually a pretty good point, but... (Score:3, Interesting)
Neither of them are really all that robust though, since any time you can overwrite the return address on the stack, you can cause execution to veer off to somewhere else. Maybe
Architecture *is* at the root cause (Score:2)
Its simple: dont mix code and data.
Re:Architecture *is* at the root cause (Score:2)
Old New Thing (Score:2, Informative)
Well, YEAH. (Score:2)
Christ, creating a SSH key takes a good 30 seconds.
Virus Execution Coprocessor (Score:2, Funny)
Given that you just can't stop the things, why not offload the burden of running them from the processor?
BIPs (Bots Infected per Second) could be the metric for performance.
PowerPC doesn't prevent buffer overflow exploits (Score:5, Interesting)
Take e.g. the iSync issue [apple.com]. 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 [linuxsecurity.com] 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" [phathookups.com].
These "insecurities" not only limited to CPU type. (Score:4, Interesting)
- 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 (Score:5, Interesting)
But it's tough to run C on that kind of architecture. [brighton.ac.uk] 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.
I call BS (Score:3, Insightful)
Oh, yeah? Try getting data from an Oracle database in FORTRAN. They used to have something called, IIRC, pro*fortran, but no more. It took me about six months of interaction with people deeper and deeper in the Oracle organization to find out that that product is "deprecated" and no longer supported. Have you ever tried porting a FORTRAN program from VAX/VMS to whatever modern environment you use? Or from a PDP-11? So her
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.
Strange nobody mentions this (Score:3, Interesting)
In Harvard architecture, data and program memory are separate and separately accessed. This has a speedup benefit, as you can access the data in the same cycle you access the program memory, but the other advantage is, a stack overflow will not corrupt your program. For an example, the Atmel AVR risc microcontroller family uses Harvard architecture.
Windows, Mac, and Linux (Score:3, Interesting)
In another article on Slashdot today it's mentioned that Eric Raymond recommends Microsoft "open document formats" and "adhere to standards". Document formats aren't really an issue with Apple, but Apple is doing a very nice job of adhering to open standards these days. BSD Unix, Java, OpenGL, PDF, TCP/IP, X11...Apple is much more programmer friendly than it has ever been. The G5 machines are also very competitive on performance.
If you need access to commercial applications, or would rather spend money instead of time to accomplish your computing tasks, Mac makes a lot of sense compared with Linux. Windows, for me, is a distant third due to the time lost dealing with security issues, and a general distaste for programming something that inelegant. Besides, I can target Windows using Java with very little pain.
Just my $.02.
NX provides little protection (Score:3, Insightful)
Random offsets won't help much -- they'll help some, but what if you can write a LOT of data into that buffer? Give it a LARGE NOP sled.
Detect when a process is doing a lot of NOPs in a row and kill it? Ok. Use "AIAIAIAIAIAIAIAI..." 'A' = 0x41 = inc %ecx, 'I' = 0x49 = dec %ecx. Together, they are an effective NOP. Hell, most of the time, "AAAAAAAAA..." is an effective NOP. Does an attacker really care what's in ECX?
The problem is NOT the architecture, NOT the OS, and NOT the language. It's not a problem with libc, stdio, strcpy, or anything else. If you haven't figured this out by now, you might want to read about computer architecture -- computers do what you tell them to. I can write secure code in which I strcpy() from untrusted data into a static buffer on the stack, on an x86 running Windows with no NX. Hell, I'll even do it in real mode.
I'm not a DJB fanboy, but he does have quite a few good points. Programmers are lazy. Write secure code.
Re:Aieeee (Score:2)
ms supporter? (Score:4, Insightful)
Re:virtulization (Score:2, Insightful)