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

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.

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