Ok, I just read most of the actual white paper (http://taossa.com/archive/bh08sotirovdowd.pdf) and this technique requires:

1.) A browser exploit that allows for a buffer overflow.

2.) A .NET control or Java applet loaded into the browser's memory whose PE header has been modified to include the malicious shell code.

Given these two things (only the 2nd of which is actually a given), you would still be constrained by Protected Mode in IE. In other words, the best you could do would be to crash the browser and maybe generate an error dialog of some sort.

If, however, the exploit was in a component that used a broker class to facility communications with a browser plugin, and that broker class was running as the current user, then you could at least access that user's files/data. If the broker class was running as system (which none do), you could take over the machine.

Flash is an example of a BAD, BAD plugin that has a broker class which could be used to facilitate an attack like this.

But let me reiterate that you first need an exploit, and that exploit must be one in an existing browser plugin (basically just Flash) that has a brokering mechanism that bypasses Protected Mode.

Without that, this doesn't do jack. Really, this is just a reliable way to defeat DEP/ASLR. Nothing more. It just makes the Flash exploit used in the hacking contest a few months back a bit more interesting. That exploit has since been patched, btw.

This is bad, but very, very overhyped.