OSNews

"it's not really game over "

So then he wasn't ironic. You agree with him. He wasn't understating then. Anything short of 'game over' is SSDD. We would need a kickass exploit turned wurm ASAP to get anything out of this... and since XP doesn't have buffer overrun protection anyways, if 0Day of that caliber already existed it would be out there. Or have hackers really been waiting for DEP to be circumvented before they release exploits? So they can maybe someday hit that extra 15% marketshare?

FAIL

No I don't. "Not game over" is not the same as that it's not a serious matter. Game over would be an error that could not possible be corrected while a serious/major error can.



Yes he is. He is trivializing it with statements like "it's not a major issue" and "it worked on XP too".



Indeed you do.

So here's the deal, really simply:

All newish programs that are compiled with the correct settings get certain protections against buffer overflows and other memory vulnerabilities. For most of these programs, these protections are effective enough that finding a buffer overflow exploit is usually only good enough to crash the program and it's hard to make it into a self-propagating worm (it's still a crash, so it's a must-fix bug in the program).

For reasons having to do with the way they accept data and plugins, by their nature browsers are not all that amenable to these memory protections. Dowd and Sotirov have shown that in certain relatively common situations, it is possible to make an exploit work despite the protections, in particular due to the way that Java and Flash work (there's still an element of luck involved for the attacker).

IE7 on Vista still uses Low Rights, so an exploit here wouldn't be able to write to your user profile or to the rest of the system (unless they also come up with an attack to break out of the sandbox). It should also be mentioned that other OSes do not ship with the protections that Sotirov and Dowd bypassed at all, so if it's game over for Vista, then it has always been game over for Mac OS X or Linux.

These problems are fixable, but it's not an immediate patch. The .NET loader issue would need to be fixed and the Java and Flash runtimes would probably need some working over. To be honest, these problems probably wouldn't exist right now if the MSJVM were still around. Unfortunately, we're now at the mercy of the Java and Flash developers until they can harden their plugins.

so if it's game over for Vista, then it has always been game over for Mac OS X or Linux.

Not perse,

http://en.opensuse.org/Security_Features

"Address Space Randomization is used for the stack and library mappings since SUSE Linux Enterprise 10 and SUSE Linux 10.1"

"The "Fortify Source" extensions in gcc and glibc are enabled for all packages by default (using -D_FORTIFY_SOURCE=2) since SUSE Linux 10.0 and SUSE Linux Enterprise 10. "

"Runtime stack overflow checking using -fstack-protector is used in some critical packages in SUSE Linux 10.1 and SUSE Linux Enterprise 10 and enabled by default for all packages starting with openSUSE 10.2. "

etc etc

Which makes me think..

I believe Linux has had (aparently, for a long time) both:

* Non-executable stack forced by compiling with gcc, and
* Virtual Adressspace Randomisation forced by the kernel

I cannot speak for MacOS X though.

If you look around you'll find Vista ain't so revolutionary after all. Might pay to explore outside that MS cubicle from time-to-time.

It is a necessary decision. DEP breaks software. It shouldn't--software should do the Right Thing (e.g. use VirtualProtect to set page permissions appropriately). But it does. This is why other platforms also allow opting out of non-exec protection. It's a necessary compromise between compatibility and security.

You might be interested to know that 64-bit processes have a much lesser ability to opt out of protection.


How about "something that can compromise a system"? That'd be a big flaw. If it were due to some systematic problem with the OS (i.e. something that could not be fixed without radically redesigning key portions of the OS), it'd definitely be game over. The methods detailed in the paper cannot. They are not buffer overflows; they are not privilege escalations; they are not any other kind of security flaw.

What they are is a way of making buffer overflows that are exploitable on Linux, Mac OS X, and Windows XP, also exploitable on Windows Vista. If there is no buffer overflow there is no problem. It is a technique for maximizing the impact of existing security flaws (my making them exploitable on Vista), not a flaw in and of itself.


If Windows XP is already susceptible to exploitable buffer overflows, and yet Windows XP remains essentially secure (which it does), then it is obvious that the ability to exploit those same buffer overflows in Windows Vista is not game-ending.


I think you must have misread or misunderstood. ASLR and DEP are not UAC or IE Protected mode. Bypassing ASLR and DEP does not mean that UAC or IE PM have been bypassed.


Yes it does.


No, even when it runs code with buffer overruns. Just because you've made my browser execute arbitrary code does not mean that you have made my browser elevate its privileges to allow it to escape its sandbox.

"It is a necessary decision. DEP breaks software."
The article make it sound like this is a decision that can be made by the application without the user interfering.

I never said it was game ending, that's the very notion i was against.
Note that the fact that these exploits havent been exploited in XP is no proof that they cant and wont be exploited in the future.



So if the locks to your apartment cant be made completely burglar proof that makes it less of a problem when you're burglarized?
The fact that a security feature cant be made fool proof doesn't make the consequences of it failing any less important.

"Internet Explorer 7 and Firefox 2 both opt out of DEP"

You can opt out? That's brilliant security design, right there."

I hope that you know that your whole rant makes no sense whatsoever?

You can opt out any security option in any OS you want: run OS as a root, without firewall, without hardened kernel, run services with root privileges, and so on.
This has nothing to do with security design.

DEP or ASLR are not mandatory.
These are options only. Linux kernel has ASLR as an option for very long time (PAX), but not every distro includes this.

If you would spent 2secs reading and trying to get what arstechnica is saying instead of masturbating with words, you would understand that MS fscked design, so they can either fix this or try something else.
As ASLR is not new (or the only way to protect system), they (MS) can take peak on better implementation (same way as they do it usually).

MS also can leave it as is and ignore the problem.