Slashdot Mirror

Don't try to screw with me, okay? I remember with SYN floods were new. I was already working with machines (in "IT" as you call it now) when the Morris Worm went around...

I work with an old programmer. He has a lot of knowledge. None of it is relevant. He's a horrible coder and an even worse CM.

Name one mainstream linux distro that has NX and ASLR on...

Oooh. There's that tricky word again.

... (not the weak forms) and is widely used please. Then we'll check its market penetration and add it to Vista's and see if we reach 1/3rd of all machines out there. ... Just because ASLR was mentioned in 1999 doesn't mean it's old hat today.

Less than 1/3rd of the machines out there on the internet are using ASLR. And of those, most are running Vista.

ASLR has been known about for ten years and had a Linux implementation for seven. Something that's widely known within a community is old hat. It doesn't matter if the proles aren't using it.

The people hacking it had more trouble than they expected because the machine was running SP1 which was new and the NX and ASLR made it a lot tougher, they had to rework their hacks they had prepared on Vista RTM before the contest.

Holy shit! Hackers who prepared a hack on a soft system had to modify their techniques when attacking a harder system? STOP THE PRESSES! THIS MUST GO ON THE FRONT PAGE!

Also, in 2009 Vista SP1 was hacked. In the latter case, it was hacked through a vulnerability in Java. They never were able to inject code onto the platform, but they didn't need to to hack in.

A system cannot be considered secure if insecure code running as an unprivileged user on the system causes it to be compromised.

If you want to say how the ASLR and NX in Vista SP1 means nothing, you should use research that is about Vista SP1 or later.

Read this. I've been to this guy's presentations. He knows his stuff:
http://taossa.com/archive/bh08sotirovdowdslides.pdf

With the above setup, you can try and exploit IE all you want, you won't get far.

Until, of course, ways to work around the memory protection are found.

I'll agree with your last statement: If Firefox had that option, then it would basically be perfect in this regard. For now though, it ends up being a matter of preference.

Personally, I prefer the solution that has been shown over time to be effective.

Oh, and I should mention that my OS of choice -- Linux -- has had no-execute bit support (what MS calls DEP) since 2004 and address layout randomization since 2005. Firefox on Linux does benefit from memory protection, just as IE does on 64-bit Vista. Full protection is generally only available on 64-bit Linux, but if it's important to you, there are distros that ship with kernels that emulate the NX bit even on 32-bit CPUs which don't really have it, or you can install your own PaX-enabled kernel on Ubuntu or whatever distro you're using.

Even on Linux, though, I'd take the protection of good code and quick patch cycles over NX bit and ASLR memory protection, if I had to choose. Which I don't.

And it isn't a general flaw in .NET - the author describes very clever ways how to use .NET applets to prepare ideal ground for a classical memory corruption attack on the browser itself. This still requires a bug in the browser or one of the plugins.

Basically what he manages to do is using a well crafted .NET DLL object putting executable code (embedded in a string constant inside the .NET DLL) to a known address, whereto he then can jump from the memory corruption exploit.

Now, to keep backwards compatibility, Microsoft did a few pretty stupid things in the implementation of the .NET applets, and because of that, putting the .NET data to a specified location in memory _AND_ marking the page executable is possible despite address space randomization and no-exec.

These implementation details can and will get fixed, though, making attacks harder again.

I suggest to read the paper, it's rather well written and very interesting.

Mark Dowd's blog post on the subject, which contains a link to the paper.

(I attended the Black Hat presentation but did not read the full paper.)

Their conclusion (debunking the whole FA):
In this paper we demonstrated that the memory protection mechanisms available in the latest
versions of Windows are not always effective when it comes to preventing the exploitation of
memory corruption vulnerabilities in browsers. They raise the bar, but the attacker still has a
good chance of being able to bypass them. Two factors contribute to this problem: the degree to
which the browser state is controlled by the attacker; and the extensible plugin architecture of
modern browsers.
The internal state of the browser is determined to a large extent by the untrusted and potentially
malicious data it processes. The complexity of HTML combined with the power of JavaScript and
VBscript, DOM scripting, .NET, Java and Flash give the attacker an unprecedented degree of
control over the browser process and its memory layout.
The second factor is the open architecture of the browser, which allows third-party extensions
and plugins to execute in the same process and with the same level of privilege. This not only
means that any vulnerability in Flash affects the security of the entire browser, but also that a
missing protection mechanism in a third-party DLL can enable the exploitation of vulnerabilities
in all other browser components.
The authors expect these problems to be addressed in future releases of Windows and browser
plugins shipped by third parties.

This presentation was how to get around features that try to prevent exploitation of memory safety bugs in applications. The intent of these features is that even if you find a buffer overflow in Notepad, you won't be able to do anything other than make Notepad crash.

These compiler and OS features try to disrupt the exploitation of memory safety bugs in various ways. Some work by detecting memory corruption (e.g. checking "stack cookies" before returning from a function that uses a string buffer). Others work by making it hard for an attacker to place shell code at a predictable memory address (e.g. DEP or ASLR).

The presenters demonstrated clever ways to get around many of these protections, but by showing how tricky it was to do so, they actually showed how effective the protections are against applications other than web browsers. To create memory that was both under their control and marked as executable, they had to take advantage of weird behavior of .NET controls (IE-only), Flash, and Java applets. The .NET control behavior looked like a bug Microsoft could fix without breaking any controls, since it involved lying about the .NET version a control was created for. The Flash behavior (a missing compiler flag) is already being fixed. The Java issue is that all Java memory is marked as executable; I don't know how hard that would be to fix, but I imagine most Slashdot users don't have to worry about this because they have already disabled Java applets.

I don't think this is devastating even to web browsers. I work on Firefox, and I know these protections haven't made us complacent about looking for and fixing memory safety bugs. Meanwhile, not all web browser security holes are memory safety bugs, so most browsers all have automatic update systems in place to ensure users receive new versions quickly.

(I attended the Black Hat presentation but did not read the full paper.)

Go here for the actual paper and code samples.

It's a very cool paper, worth reading, but the neowin article greatly overstates matters.

More details would have been nice.

Well, ok.

http://taossa.com/archive/bh08sotirovdowd.pdf

Here's some code for ya too

http://taossa.com/archive/bh08sotirovdowdcode.zip

Enjoy!

More details would have been nice.

Well, ok.

http://taossa.com/archive/bh08sotirovdowd.pdf

Here's some code for ya too

http://taossa.com/archive/bh08sotirovdowdcode.zip

Enjoy!

It's news because it's a general method for code execution from a common class of NULL pointer dereferences. He turned something that most people consider a crash bug into a code execution bug. Here's a simpler example from Dowd's blog: http://taossa.com/index.php/2007/04/15/bored-games/

The other reason why it's news is that his method for exploiting Flash in this case is technically brilliant. I can understand if you don't appreciate it, but any security people out there are just overwhelmed.

It's not a salt, it's just an artifact of how the Flash VM operates. There's a year-old post on Dowd's blog with a much simpler example of the same class of vulnerability: http://taossa.com/index.php/2007/04/15/bored-games/

Basically, the vulnerability occurs when you can write to an arbitrary offset from NULL. This is probably a common enough mistake that no one has been looking for because NULL derefs are usually just a crash bug. What Dowd has shown is that with a little application knowledge, and control of the deref value, you can make this type of bug into a perfectly reliable exploit that is unaffected by application hardening like stack canaries and heap checking.

(book by Dowd, McDonald, Schuh) is well worth a look: http://taossa.com/index.php/author/mark/