Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
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.
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.
Link to Original Source