Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is the x86 Architecture Less Secure?

Cliff posted more than 9 years ago | from the oh-my-buffers dept.

Security 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?

cancel ×

315 comments

thats because (3, Funny)

Anonymous Coward | more than 9 years ago | (#12388726)

all x86 processors have an evil bit

shut up hets (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12388729)

gnaa rules

PR as Journalism (not) (5, Interesting)

rossifer (581396) | more than 9 years ago | (#12388732)

Paul Murphy [cio-today.com] , I'd like you to meet Paul Graham [paulgraham.com] . 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) (3, Interesting)

figleaf (672550) | more than 9 years ago | (#12388818)

Maybe Apple paid him too. [washingtonpost.com]


Re:PR as Journalism (not) (1, Funny)

Anonymous Coward | more than 9 years ago | (#12388865)

Murphy and Graham? That's a match made in heaven if ever there was one. Imagine the articles; "SCO own LISP copyrights, offer licenses to those suffering from speech impediments".

Re:PR as Journalism (not) (5, Interesting)

ErikTheRed (162431) | more than 9 years ago | (#12388889)

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:PR as Journalism (not) (1)

Anonymous Luddite (808273) | more than 9 years ago | (#12389161)

>> is generated by PR firms, advocacy groups, political parties, etc., given a very thin coat of paint, and slapped on the page

Writers are people. People are lazy. Small wonder PR firms are smart enough to exploit it...

Happy Paul Murphy Day (5, Funny)

Anonymous Coward | more than 9 years ago | (#12388736)

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

Ugh... (-1, Offtopic)

imadoofus (233751) | more than 9 years ago | (#12388737)

This guy is back again?

FUCK (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12388738)

Hello? FUCK!

RISCy (5, Insightful)

FidelCatsro (861135) | more than 9 years ago | (#12388741)

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 (0)

Anonymous Coward | more than 9 years ago | (#12388790)

Meow Cats claws moderators...This is the issue People . If MS knows the Risk(pun) then whey the hell do they still use this feature.
It may be a bit more secure on risk(another pun) . Hardly though as they still take as little intrest in the security.

Re:RISCy (0)

Anonymous Coward | more than 9 years ago | (#12388794)

Because it's cheaper, standardized, and has backwards-compatibility.

Re:RISCy (0)

Anonymous Coward | more than 9 years ago | (#12388823)

? they are programing to a flaw because the flaw has backwards-compatiblity and is cheaper ? . I think you misunderstood me , im not insulting CISC or x86 but insulting MS relying on this feature

FidelCatsro

Re:RISCy (5, Insightful)

Michalson (638911) | more than 9 years ago | (#12389105)

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.

Re:RISCy (5, Insightful)

nocomment (239368) | more than 9 years ago | (#12388844)

Bingo. Well said. OpenBSD runs on x86, does it have this flaw?

Re:RISCy (2, Interesting)

ArbitraryConstant (763964) | more than 9 years ago | (#12388980)

Exactly.

The security advantage of MacOS X is a lack of braindead design decisions, it has nothing to do with PowerPC.

Re:RISCy (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12389014)

Yep , that and the BSD core ;) hehe .
Linux/ free,darwin ,open,net:BSD don't have these problems .
if you choose a specific architecuture such as x86 then you don't dont program to its weakness you go for its strengths like the BSDs and linux do .

Fcat!

Real Solution -- Signetics Write Only Memory! (1)

farrellj (563) | more than 9 years ago | (#12389094)

Think about it...if a virus could never read it's code out of memory, you would never suffer from it...worms would die, and all malware would stop working! It would be great!

Better yet, you can use the Signetics chips in both PCs *AND* Macs!

ttyl
Farrell

Is this the Astrodome? (5, Insightful)

winkydink (650484) | more than 9 years ago | (#12388743)

2 articles in under 4 hours submitted by an "anonymous reader" that point to Paul Murphy at CIO Today. Hmmmm... Astroturf anybody?

Re:Is this the Astrodome? (1)

FidelCatsro (861135) | more than 9 years ago | (#12388764)

... Hes a busy boy aparently . Perhaps a coincidence .. or sponsership..
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? (2, Funny)

stevesliva (648202) | more than 9 years ago | (#12388862)

Draw dubious conclusions from circumstantial evidence that question the anti-wintel open source orthodoxy, get cited on Slashdot!

Right this instant, I'm working on my "Windows better for pirating media files" opinion piece. It's a surefire winner.

Re:Is this the Astrodome? (0)

Anonymous Coward | more than 9 years ago | (#12389270)

Be sure to write it under the pseudonym Paul Murphy.

I gotta call bullshit on this one... (5, Informative)

HotNeedleOfInquiry (598897) | more than 9 years ago | (#12388750)

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.

Re:I gotta call bullshit on this one... (2, Insightful)

Anonymous Coward | more than 9 years ago | (#12389050)

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 providing standard library functions that aren't vulnerable to being misused in this way, bounds-check, provide higher-level libraries, etc. If it doesn't, then it shares some of the blame.

A manager can reduce risk by giving the programmers the resources to do their jobs properly, mandating safer languages, instituting code reviews, pushing back schedules instead of skipping QA, etc. If they don't, they share some of the blame.

Security is only as strong as the weakest link, and nobody in the chain is ever perfect.

Re:I gotta call bullshit on this one... (0)

Anonymous Coward | more than 9 years ago | (#12389069)

You think that driving the safest car on the market is silly? You're crazy if you don't know everyone should drive Volvos.

Re:I gotta call bullshit on this one... (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12389146)

I think his point was that driving the safest car may not be recognized as the most important criteria while buying a car...

and in reality it was just symbolic, because anyway volvos theese days are just as plastic as any car

Re:I gotta call bullshit on this one... (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12389247)

New Volvos are notorious for randomly breaking down. You might survive a crash more easily, but I'd rather have a reliable car that makes it easier to AVOID a crash.

Bad analogy (1)

sesaetaen (637921) | more than 9 years ago | (#12389190)

Driving a safe car provides you an extra chance of making it in a crash.

Writing poor code is more like not utilizing the workings of your vehicle (braking only with the parking brake?), hence driving it insecurely because of sloppiness.

I've been running Windows on PPC... (0)

Reverend528 (585549) | more than 9 years ago | (#12388751)

And it's so secure that even I can't get admin privileges...

How Long? (1, Interesting)

blueadept1 (844312) | more than 9 years ago | (#12388753)

x86 has been around how long? 15+ years? And they just begin discussing this now?

Yeah, ok. (0)

Anonymous Coward | more than 9 years ago | (#12388759)

Or, "Is Mac OS X on PPC less secure?" - It would be the same, worthless article if it were provided by Paul Thurott, on the opposite side of the fence.

This is just another guy that just got done giving Steve Jobs a blowjob. Let's move on.

Funny... (5, Insightful)

scovetta (632629) | more than 9 years ago | (#12388761)

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

Not so... (4, Insightful)

dhowells (251561) | more than 9 years ago | (#12389011)

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'

Stack (4, Interesting)

Sloppy (14984) | more than 9 years ago | (#12388766)

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 (0)

Anonymous Coward | more than 9 years ago | (#12388815)

why would up equal non-allocated?

Overflowing memory is bad, period.

Re:Stack (1)

mce (509) | more than 9 years ago | (#12388853)

Yes overflowing is always bad, but overflowing down opens up a lot more opportunities for the kiddies.

Re:Stack (2, Insightful)

Sloppy (14984) | more than 9 years ago | (#12388874)

why would up equal non-allocated?
Well, some direction needs to be unallocated.
Overflowing memory is bad, period.
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 "buffer overflow" means.

Re:Stack (0)

Anonymous Coward | more than 9 years ago | (#12388850)

Actually, on the x86 the stack can grow upwards or backwards. On Win32, the stack is set to grow upwards so that an exception is generated on stack overflows

Re:Stack (1)

enosys (705759) | more than 9 years ago | (#12388857)

Having the heap grow forwards and the stack grow backwards made sense back before multitasking and virtual memory. It's just one of the many archaic things in the x86 architecture.

Re:Stack (2, Insightful)

kernel_dan (850552) | more than 9 years ago | (#12388861)

The stack goes backwards and the heap goes upwards. They grow in opposite directions to minimize wasted space. You would prefer heap overflows to overwrite the stack frames and return addresses?

Careful programming when dealing with memory in a language without builtin bounds checking is the solution to this problem.

Re:Stack (5, Interesting)

CajunArson (465943) | more than 9 years ago | (#12388877)

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 (0)

Anonymous Coward | more than 9 years ago | (#12389076)

How exactly do you intend to overwrite the return address on the stack such that the IP will point to your new code?

With an upward growing stack, the return address is below you. Anything above the stack is unallocated pages, or possibly the heap ..

Sure, you could corrupt the heap but you're still not going to get the IP to point to your malicous code.

Re:Stack (1)

Lemming Mark (849014) | more than 9 years ago | (#12389102)

How can you affect the behaviour of functions above you on the stack which won't have been called yet?

Growing in a different direction is still not a total solution (the ideal solution being not to have overflowable buffers).

Re:Stack (0)

Anonymous Coward | more than 9 years ago | (#12388879)

  • When multiple threads are running in the same address space, you lose that assurance anyway.
  • The VM handles the stack anyway, and stack space is limited. Usually to a few megabytes.
  • The PowerPC stack grows downwards as well.
  • The only architechture I know of that doesn't is HPPA, and that hasn't saved it from buffer overflow attacks.

Re:Stack (0)

Anonymous Coward | more than 9 years ago | (#12388893)

Backwards? PPC stacks grow toward lower addresses, so running off the end of the buffer will still overwrite return addresses, etc, no?

Re:Stack (1)

temojen (678985) | more than 9 years ago | (#12388936)

It's totally insane.

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 at home which I'll check after work, but I don't remember anything about the stack growing up.

Re:Stack (0)

Anonymous Coward | more than 9 years ago | (#12389098)

ppc's dont have a stack.

so i guess, at least for the purposes of this discussion, that's the ultimate secure platform.

Re:Stack (1)

kvigor (66615) | more than 9 years ago | (#12388998)

The stack grows downward on the vast majority of architectures, including PowerPC, ARM, SPARC, and MIPS. The only architectures I've come across where stacks grow up are PA-RISC and i960.

So if you cponsider this is a sign of CPU inferiority, well, I hope you're an HPUX fanboy.

Re:Stack (5, Insightful)

pclminion (145572) | more than 9 years ago | (#12389000)

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 (1)

ebyrob (165903) | more than 9 years ago | (#12389177)

Here's a novel question: Why even put the stack and heap in the same virtual page on modern operating systems?

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

Montreal? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12388768)

hahahaha

Maybe I'm missing something here... (2)

HotNeedleOfInquiry (598897) | more than 9 years ago | (#12388774)

But doesn't pretty much everyone use a compiler. And doesn't the compiler pretty much insulate you from such issues? What am I missing?

Re:Maybe I'm missing something here... (1)

aklix (801048) | more than 9 years ago | (#12388828)

Remember now, microsoft writes the most popular windows compiler...

Re:Maybe I'm missing something here... (2, Insightful)

Locke2005 (849178) | more than 9 years ago | (#12388849)

The issue is whether the stack grows downwards (from higher memory address to lower) or upwards (from lower memory addresses to higher). If the stack grows downwards, then overrunning an array allocated on the stack (due to missing bounds check, which is bad programming) can overwrite a return address on the stack. Then the function can return to an arbitrary address. If the stack grew upwards, this would not be possible. No, the compiler cannot insulate you from basic CPU design. On the other hand, not bounds checking array accesses should always be considered a "bug".

Re:Maybe I'm missing something here... (1)

(void*) (113680) | more than 9 years ago | (#12388904)

It does not matter if the stack grows downwards or upwards. In any case, if the address of the return value is predictable, it is possible to overwrite it.

Re:Maybe I'm missing something here... (1)

Locke2005 (849178) | more than 9 years ago | (#12388937)

With a negative array index, yes. But most buffer overrun exploits are due to string copies (eg. strcat or strcpy) not bothering to check for buffer length. In which case, the return value you are overwriting must be ABOVE the string buffer in memory.

Re:Maybe I'm missing something here... (1)

(void*) (113680) | more than 9 years ago | (#12389211)

There can be many ways to cause buffer overrun, not just in strings. The solution you propose addresses only strcpy or strcat, and only on the PC, with a specific memory layout design.

Re:Maybe I'm missing something here... (1)

prockcore (543967) | more than 9 years ago | (#12389043)

If the stack grew upwards, this would not be possible.

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.

Re:Maybe I'm missing something here... (1)

HornWumpus (783565) | more than 9 years ago | (#12389268)

On the other hand, not bounds checking array accesses should always be considered a "bug".

In a word NO.

The discision to bounds check arrays is not subject to single answer solutions.

The Real Issue: Control (0)

Anonymous Coward | more than 9 years ago | (#12388785)

All in my opinion:

From recent news it smells like what will eventually happen is the internet and new architectures will all be redesigned to benefit one closed source OS. Do you think /\/\$ will go down without a fight? Nope, it'll be kicking and screaming one war at a time, IMO. This is the beginning of the "let's change everything to lock them all in" war which will be waged along side the war of patents. Just like the spoiled simpleton who declares "If I can't have it, no one will!" before going batshit crazy.

So the wars will begin over BIOS, new and old architectures, patents, etc. The question is: Will /\/\$ leap to the top again? Or will FOSS prevail? Remember Amiga? OS/2? Corel Linux? Etc? I'm sure one warlord will try and lock everyone into some new architecture because they will likely lose if they remain x86 only. I've seen this coming for several years and knew it was only a matter of time.

RISC isn't the solution (5, Informative)

ikewillis (586793) | more than 9 years ago | (#12388786)

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.

Re:RISC isn't the solution (2, Informative)

ArbitraryConstant (763964) | more than 9 years ago | (#12388908)

Interestingly, PowerPC lacks a per-page execute disable as well. It has nothing to do with whether an architechture is RISC or not.

Re:RISC isn't the solution (1)

kvigor (66615) | more than 9 years ago | (#12389036)

The MMUs on various PowerPCs vary; I know that there definitely is an executable bit in the page mapping table for the 40x family.

Administrate isn't a word (1)

lheal (86013) | more than 9 years ago | (#12388973)

Informative post, but it's "Administer".

But besides that, whether a buffer overflows or not is not a hardware issue, it's a program bug. If a programmer is so unclever as to allocate a buffer using a temp array on the stack and not bounds-check his code, well, unemployment should result.

Yeah, someone did piss in my Wheaties this morning.

Yellow wheaties. (1, Funny)

Anonymous Coward | more than 9 years ago | (#12389018)

"Yeah, someone did piss in my Wheaties this morning."

That was me. Sorry.

Re:Yellow wheaties. (1)

lheal (86013) | more than 9 years ago | (#12389067)

>That was me. Sorry.

No problem. Thanks for owning up to it.

Re:Administrate isn't a word (1)

mikael (484) | more than 9 years ago | (#12389120)

Don't forget NUL terminating a string:


void process_string( char *pstr )
{
char tempbuf[1024];

strncpy( tempbuf, pstr, 1023 ); // Avoid overflow

buffer[strlen(buffer)-1] = '\0';
}

Re:Administrate isn't a word (1)

mikael (484) | more than 9 years ago | (#12389132)

That should be:


void process_string( char *pstr )
{
char tempbuf[1024];

strncpy( tempbuf, pstr, 1023 ); // Avoid overflow

tempbuf[strlen(tempbuf)-1] = '\0';
}

Re:Administrate isn't a word (1)

kvigor (66615) | more than 9 years ago | (#12389262)

That would also be wrong. strncpy does *not* null-terminate the buffer if it would overflow, so strlen(tempbuf) is not defined in that case. You want something like:
{
char tempbuf[1024];

strncpy(tempbuf, pstr, sizeof(tempbuf) - 1);
tempbuf[sizeof(tempbuf) - 1] = 0;
}

Re:Administrate isn't a word (1)

Anonymous Luddite (808273) | more than 9 years ago | (#12389241)

>> '\0';

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... (3, Funny)

autocracy (192714) | more than 9 years ago | (#12388796)

F00FC7C8

Still here? Dammit...

big deal.. (2, Funny)

pixas (711468) | more than 9 years ago | (#12388802)

..so what if I have 0.999997 viruses in my CPU?

1993 called - they want their flamewar back (5, Funny)

nosferatu-man (13652) | more than 9 years ago | (#12388824)

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

PageRanking Submissions. (0)

Anonymous Coward | more than 9 years ago | (#12388863)

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

Bet it got a low PageRanking(TM).

Re:1993 called - they want their flamewar back (0)

Anonymous Coward | more than 9 years ago | (#12388925)

A troll responding to a troll(Paul Murphy). Nice.

News Flash! x86 sucks! Film at 11! (1)

GeekDork (194851) | more than 9 years ago | (#12388830)

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! (4, Funny)

carcosa30 (235579) | more than 9 years ago | (#12388831)

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. (4, Insightful)

ArbitraryConstant (763964) | more than 9 years ago | (#12388835)

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

Hockney Twang (769594) | more than 9 years ago | (#12389110)

OSes like Linux or MacOS don't do them on any architechtures. Stack protections like propolice are a compile-time option...

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

ArbitraryConstant (763964) | more than 9 years ago | (#12389179)

"And no Linux distribution allows you to make use of your own compiler flags?"

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. (2, Interesting)

Ann Elk (668880) | more than 9 years ago | (#12389210)

OSes like Linux or MacOS don't do them on any architechtures.

Linux does [lwn.net] support limited stack and library randomization. However, there are questions [stanford.edu] as to the effectiveness of these techniques.

virtulization (1)

minus_273 (174041) | more than 9 years ago | (#12388851)

for starters, the x86 architecture can't be virtualized which is a real big setback.

Re:virtulization (2, Insightful)

Anonymous Coward | more than 9 years ago | (#12389039)

Except by VMware and Virtual PC. Oh wait, I guess it can be virtualized!

Aieeee (-1, Redundant)

dmh20002 (637819) | more than 9 years ago | (#12388859)

Paul Murphy again? He's definitely getting some page impressions out of this.

Re:Aieeee (2)

Laura_DilDio (874259) | more than 9 years ago | (#12388901)

Paul, let me explain how to be an industry analyst... 1) NEVER NEVER NEVER refer to anything that puts Microsoft in a bad light. After all, they pay the bills. 2) NEVER NEVER NEVER mention pinko-commie-bastard linux without mentioning how the TCO is lower on Windows, reliability is a myth, and security is virtually non-existent. 3) Lastly, land a gig working for a real tech think-tank, like the Yankee Group (TM). CIO Today? Who reads that rag anyway? You get more press from these slashdot lusers than you do from a bunch of clueless pointy-haired bosses. Love, Laura Groom of the Stool to Lord Bill

but i does run on risc (0)

Anonymous Coward | more than 9 years ago | (#12388860)

nt4 and some early versions of windows 2000 run on alpha ,mips i think that there was a sparc version to but that one did not last for long.

Linux, OS/2, BSD, etc. (0)

Anonymous Coward | more than 9 years ago | (#12388869)

So according to this article, Linux, OS/2, BSD, Solaris for x86, etc. are all just as insecure as Windows on x86? What about when WindowsNT ran on MIPS or RISC or Alpha? Was that not insecure?

Isn't this the same guy... (-1, Redundant)

Rimbo (139781) | more than 9 years ago | (#12388883)

...who wrote that SCO/IBM article 3 or 4 Slashdot front-page articles ago?

I doubt x86 inherently flawed (4, Informative)

rice_burners_suck (243660) | more than 9 years ago | (#12388890)

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.

Re:I doubt x86 inherently flawed (0)

Anonymous Coward | more than 9 years ago | (#12389091)

The virtualization layer knows about x86 instructions, not about higher level software constructs.

How's the virtualization layer supposed to know which "rep stos" instruction is your program legitimately initializing a large array on the stack and which one results from a worm exploiting a buffer overflow in your web server?

There's absolutely no way a virtualization system can prevent attacks without having a deep understanding of the operating system and/or application you're running. That's not how (general purpose) virtualization systems work.

Re:I doubt x86 inherently flawed (1)

NoMercy (105420) | more than 9 years ago | (#12389145)

There's only really one big flaw, it's ancient, and it's kept that way for backwards compatability.

Oneday we'll look at x86 like VHS to the DVD, or like magnetic tape cassettes to the mp3 player.

NX bit (2, Interesting)

BinaryJono (546830) | more than 9 years ago | (#12388894)

while the NX bit can help prevent the execution of malicious code on the stack after a buffer overflow, it doesn't solve the security problem posed by overflows. return-into-libc attacks can easily be executed and will become much more prevelant as NX-enabled PCs filter into the mainstream. address space randomization can help make rilc attacks harder on 64-bit architectures but is pretty useless on 32-bit archs.

ms supporter (0, Flamebait)

cg0def (845906) | more than 9 years ago | (#12388909)

Soooo, how much money did that guy get paid to find MS another excuse not to fix their buggy OS?

ms supporter? (3, Insightful)

Blitzenn (554788) | more than 9 years ago | (#12389032)

Did you happen to actually read the article? The guy ends by blatantly stating that there is no sane reason to choose a PC over a mac. How can you possibly see this guy as an MS supporter,.. unless of course you didn't really read the article.

More theoretical than practical (1)

ebyrob (165903) | more than 9 years ago | (#12389062)

Whare have we heard that [atstake.com] before?

Secure programming is the answer (0)

Anonymous Coward | more than 9 years ago | (#12389070)

This will always be a problem until programmers read a good book on secure programming [amazon.com] or take a secure programming class [liveammo.com] to learn how to write code without heap and buffer overflow vulnerabilities.

Windows doesn't take advantage of the hardware (2, Interesting)

wiredbuddy (595891) | more than 9 years ago | (#12389095)

I just read this article recently in Embedded Systems Programming magazine. http://www.embedded.com//showArticle.jhtml?article ID=55301875 [embedded.com] After a detailed explanation of the hardware protection features built into the x86 (since the 80386), the author makes the following statement towards the end of the article: "Too bad Microsoft doesn't use this feature. Windows has been plagued by buffer-overflow bugs that could easily be prevented by the processor's segmentation features. Alas, even though these features have been built into every x86 chip for more than 15 years, Microsoft has never used them. Instead, Windows creates a "flat" memory system with no segmentation, no tasking, no bounds checking, and no privilege protection, and then struggles to duplicate all those features in software. The result has been famously ineffective."

Re:Windows doesn't take advantage of the hardware (1)

Ann Elk (668880) | more than 9 years ago | (#12389155)

"Too bad Microsoft doesn't use this feature. Windows has been plagued by buffer-overflow bugs that could easily be prevented by the processor's segmentation features. Alas, even though these features have been built into every x86 chip for more than 15 years, Microsoft has never used them. Instead, Windows creates a "flat" memory system with no segmentation, no tasking, no bounds checking, and no privilege protection, and then struggles to duplicate all those features in software. The result has been famously ineffective."

Neither Linux nor the BSD variants use the x86 segmentation hardware, yet they are not "famously ineffective".

Architecture *is* at the root cause (1)

nurb432 (527695) | more than 9 years ago | (#12389261)

However, all other non Harvard architectures will suffer the same fate, as they all have the same flaw. RISC isnt a magic trick to fix all evils.

Its simple: dont mix code and data.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...