Slashdot videos: Now with more Slashdot!

View

Discuss

Share

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

scribbles89 sends in a story that originally ran in SearchSecurity; it sounds like it could be a game-changer. "While this may seem like any standard security hole, other researchers say that the work is a major breakthrough and there is very little that Microsoft can do to fix the problems. These attacks work differently than other security exploits, as they aren't based on any new Windows vulnerabilities, but instead take advantage of the way Microsoft chose to guard Vista's fundamental architecture. According to Dino Dai Zovi..., 'the genius of this is that it's completely reusable. They have attacks that let them load chosen content to a chosen location with chosen permissions. That's completely game over.'"Update: 08/08 14:23 GMT by KD: Changed the link, as the story first linked had been lifted without attribution.

These techniques are being seen as an advance that many in the security community say will have far-reaching implications not only for Microsoft, but also on how the entire technology industry thinks about attacks. Expect to be hearing more about this in the near future and possibly being faced with the prospect of your "secure" server being stripped completely naked of all its protection.

From this paragraph it sure sounds like the author of the article hasn't got a clue.

This is a security Vista issue because it concerns how.NET was implemented on Vista. The method "may" be used on "possibly" other systems but as of yet it does not affect XP or OS X, as per the article. RTFM please.

The fact of the matter is that no OS is completely safe but MS and Apple like people believe so since it's their marketing that dictates the direction of the OS.... and yet there is not much more in the article to be ale to say anything for sure.

The bias that most have is due to the marketing. If I am told I can do such and such with such, I better be able to. If I am told it's about security don't hide behind the marketing be upfront about the issues. Unfortunately form MS and Apple the only true fact is that they will try to milk as much as we are willing to give them.

It wasn't on anybody's security radar screen until, if I recall, the Morris Worm. So you could have an app that passes all the items on the best security checklist in existence, but if it read input into a local variable without checking the length (as nearly all of us C programmers did, back in the day, and some apparently still do), then your app was wide open.

The discovery of a new class of attack vector can indeed have far-reaching implications, beyond the vendor that's the target of the first practical demonstration.

But it' not an everyday occurrence. It ain't easy to to think up something that is truly new in an area where there is a lot talent working. Mostly, you come up with refinements and insights on what is already known. Richard Feynman discussed this in one of his books, that there was only one point in his entire career where, for a few hours, he knew something about the laws of physics that nobody else did.

So it's probably still just saber rattling, but such a thing could exist.

It clearly means any environment which results in a compilation stage within the browser:

* Java - JIT*.NET - JIT* JavaScript - JIT on some browsers now

Why? Because they compile into executable code within a browser. Clearly the compiler/JIT/browser should sandbox these. But to compile code into memory, you need to disabled the NX bit check... that's one security mechanism bypassed. And I presume that address randomisation doesn't work for these JITs either. Yet.

Well guessed. Now we have the link to the real article, we can confirm this to be the case. You still need another vulnerability to execute the code though. Having executable code on a well placed position in the process is step one, actually executing it is step two. They use a well known vulnerability to do so.

I usually like to pick a nit as much as anyone, but if one reads "scripting language" as "environment in which script can run in a browser", which is not that much of a stretch, it makes perfect sense.

That's even likely. He's not the one that found the exploit. He's a journalist.

It's even likely that all he got was the paper (if that) and that it went waaaaaay over his head, so he most likely asked a few people who he deemed more clued and they nodded their head and confirmed that yes, that's hot stuff.

So he wrote as best as he can.

Just because the article doesn't really tell anything doesn't mean the threat doesn't exist. It only means the author didn't understand it too well and wanted to have a lurid tale.

They also don't point out whether this breaks out of the IE sandbox or not. This makes a big difference, as if they can't break out of the sandbox, it makes any attack fairly useless on a correctly configured machine using IE. More details would have been nice.

Well, if they can really get past "all memory protection safeguards", that means the code can just overwrite your running kernel. I doubt that sentence was really intended to say that, though. it probably means specifically the ones new to Vista over XP that were listed.

if they can't break out of the sandbox, it makes any attack fairly useless on a correctly configured machine using IE.

Every time an exploit occurs, people start blabbering about "correctly configured" machines, completely missing the point. What is really important is this: does it work on an out-of-the-box Vista or not?

Well it does say "By taking advantage of the way that browsers, specifically Internet Explorer, handle active scripting and.NET objects, the pair have been able to load essentially whatever content they want into a location of their choice on a user's machine." Since we know Vista ships with IE7 and the sandbox enabled we can guess from TFA that they have found a way out of the sandbox.

"Properly configured" in the case of IE's sandbox means "I didn't turn off UAC". So, no, an attack that's stopped by IE sandboxing does not work on out-of-the-box Vista. It would only work on the sort of Neowin-reading "power users" who turn off security features to gain (perceived) speed and convenience.

All security measures have to account for ID-10-T errors, and "error 60" (cm in front of the screen).

UAC might be a good theory, but it fails dramatically by either a) causing users to turn it off, or b) training them to automatically punch "accept". If the warning was exceptional, or infrequent, it would be much more effective.

It would only work on the sort of Neowin-reading "power users" who turn off security features to gain (perceived) speed and (actual) convenience.

So you are stating that UAC is not a real inconvenience just perceived?

I'm currently running Server 2008 on my home desktop, and yes I would say that UAC is not a real inconvenience at all. I don't spend all my time tweaking settings or installing/uninstalling software though; in normal day-to-day usage, I almost never get prompted by it.

Mind you, I also don't run as an admin, so perhaps that has something to do with it - but then, you shouldn't be running as admin anyway.

While this is true as far as it goes, the article claims that the exploit has "no workaround". If that's really true (and the details are too sketchy to make any kind of judgment about that), then it would appear that even a "correctly configured" machine still has some degree of vulnerability.

From reading this, it seems to me that what they published is code that, one by one, bypasses every memory protection feature on Vista. This means a process that is allowed to start, using these techniques, can get full system privileges.

However it does still require that code be run in the first place. The document does include apparently recent exploits, for JavaScript, Flash,.NET, for recent versions of IE and Vista.

The question is, do they work on other browsers? For example, the.NET code probably wouldn't. The JavaScript exploit relies on filling the IE heap with 100mb of code, which I'm not sure would work on Firefox.

So the bottom line is that before, if an exploit broke through IE, it landed with user-based privileges on the system. Using this code, an exploit that breaks out of IE lands with Admin access.

They also don't point out whether this breaks out of the IE sandbox or not. This makes a big difference, as if they can't break out of the sandbox, it makes any attack fairly useless on a correctly configured machine using IE. More details would have been nice.

From TFA:

By taking advantage of the way that browsers, specifically Internet Explorer, handle active scripting and.NET objects, the pair have been able to load essentially whatever content they want into a location of their choice on a user's machine.

From/. Summary:

They have attacks that let them load chosen content to a chosen location with chosen permissions.

I think it's pretty clear that it is out of the sandbox and has full access to the backyard and house, regardless of how Vista is configured.

Too bad it doesn't explain what they actually did and just says "ooo, this is really bad"

In the days of the Web there is a rule that if someone tells the press before they publish the paper, they are full of it.
They haven't told Microsoft, so they can't even claim that they are not releasing the details to allow for a fix.

CF all those 'studies' that 'prove' porn is bad or watching TV turns kids into Martians or whatever. Every time that stuff hits the press the paper is 'to be published' which is a good way to prevent opponents getting in a response.

Too bad it doesn't explain what they actually did and just says "ooo, this is really bad"

In the days of the Web there is a rule that if someone tells the press before they publish the paper, they are full of it. They haven't told Microsoft, so they can't even claim that they are not releasing the details to allow for a fix.

They're presenting their findings at a black hat conference this week. What makes you think they have any motivation to help MS fix it beforehand? Did it ever occur to you, as people who break security systems they think impede their own and other peoples freedom, they might, just might, have a strong motive to punish anyone who installed it and drive them off Vista?

So you're claiming the "Wont someone please think of the children" defense?
If they don't want to use Vista or any other piece of software, that's their choice, but to think that somehow they are doing this to protect me by making me see the "error of my ways", well that's a giant bag of crap. They are called PERSONAL choices for a freaking reason.

By supporting Microsoft you are in reality impeding on others freedom since Microsoft is on an all out war against anything that can have even the slightest chance of removing their monopoly. Also by showing people all the faults in Windows design decisions some people (in my mind futile) think that Microsoft will pay more attention to security in future releases and not just tack on stupid things like UAC and other false security stuff.

I couldn't care less about Microsoft if they would just leave others alone. They're yesterdays news and the only things that annoys me personally is their hellbent intent on destroying open source.

From TFA:"While Microsoft hasn't officially responded to the findings, Mike Reavey, group manager of the Microsoft Security Response Center, said the company has been aware of the research and is very interested to see it once it has been made public."

So, Microsoft isa.) Not currently aware of the details of the exploit andb.) Doesn't plan (or, apparently, want) to GET the details until the details are PUBLISHED.

Apparently, Microsoft's "Security Response Center" has no idea that they have a window of opportunity to fix the problem BEFORE the details are in the wild. Why would we want that? Nah, we don't need to be pressing for details. We'll figure it out when our customers start screaming about exploits.

I've thought MS was somewhat incompetent on security, but this is mind boggling.

I'm sure I'm not the only one who remembers running some little script [slashdot.org] with normal user privileges, and suddenly seeing the prompt change from
user@computer:~$
to
root@computer:~#

And, well, that had been around forever, apparently. And, well, it was fixed the next day.

The moral? Horrendous, gaping security holes do exist, and are found from time to time. And they get fixed (faster in FOSS than Windows, but they still get fixed). Of course, some OSs are more equal than others when it comes to general security and user-centric design, but I just can't believe for a minute that this is some life-shattering, end of the world event for Microsoft.

Extraordinary claims require extraordinary proof. The linked article provides... vagueness. It mentions that used a browser (which one?) And that it has something to do with defeating the NX bit. I'm guessing that it's not nearly as severe as this article's hyperbole makes it seem.

TFA does imply that the exploit takes advantage of an assumption at the OS level that.NET objects are automatically safe, and gives them the same privileges as the browser itself. It also says that the exploit takes advantage of a multi-homed attack using different scripting methods. Given that information, I'd venture a wild-assed guess that the exploit most likely uses JAVA and/or ActiveX to load a downloaded/forged.NET object which in turn loads arbitrary code as described.

If there's truth to the assumption about.NET objects, then it's a monumentally stupid decision on Microsoft's behalf. But there is a (temporary) fix that can be patched into the OS by requiring a signature. Yes, those can be forged. Yes, it's a stop-gap measure. But if you require authentication from online servers (remember, this is a drive-by online exploit, so it's safe to assume that anybody who needs to validate a signature like this has Internet access), then it is an improvement until it can be fixed properly.

The most basic security measure in a OS is that you know what type of file you are dealing with. Am I about to open a harmless text file OR about to run a executable I just downloaded from a russian site?

How do you know? By the extension, so what does MS do? They hide the extension of files. Whopee! Then they allow executables to choose their own icon INCLUDING those that look just like the system own icons for other filetypes.

Can you say braindead? Can you say asking for trouble?

And for what? So that the file-explorer looks a bit cleaner? Hardly because what does MS then do in detail mode, add a column to list the type that is often nothing more then just saying "this is an EXTENSION file". WHOOPEE!

In other views it saves a grand total of 4 characters at the cost of a hell of a lot of basic security.

But MS is so concerned by the clean look that for a shortcut they add ' - shortcut' a grand total of 11 characters AND a icon on top of the icon.

IF MS is EVER going to learn about basic security they would add a similar tiny icon to be displayed over files that are executable. Can be done easily, but MS doesn't think about security, they want a simple clean look that doesn't require the user to use any brain cells even if that user then creates heaps of trouble for himself.

It is the same with allowing emails to contain executable code etc etc. Shinyness over security or even usability.

It currently isn't known whether these exploits can be used against older Microsoft Operating Systems, such as Windows XP and Windows Server 2003, but since these techniques do not rely on any one specific vulnerability, Zovi believes that we may suddenly see many similar techniques applied to other platforms or environments.

Although I have a nagging feeling that this isn't as groundbreaking as Neowin.net makes it to be.

I suspect you're right. Reading the article, it sounds like they have a way of using browser plugins as a way to get around the address space randomization features in Vista. That's a big deal, and it really might be as hard to patch as they claim. But address space randomization was never a silver bullet and even without it, all they've done is put is back to a Windows XP world.

What would be interesting is if they can extend the attack to Linux, which also does a certain amount of randomization. If they can do that, then they've got a reusable, general purpose attack. But, as it stands, it certainly doesn't sound like anything too new. People have been attacking Flash, ActiveX, Java applets, and other plugins for years.

"If you think about the fact that.NET loads DLLs into the browser itself and then Microsoft assumes they're safe because they're.NET objects, you see that Microsoft didn't think about the idea that these could be used as stepping stones for other attacks. This is a real tour de force."

So in other words, like 80+% of the other exploits on web, the exploit only works if you use Internet Explorer?

"If you think about the fact that.NET loads DLLs into the browser itself and then Microsoft assumes they're safe because they're.NET objects, you see that Microsoft didn't think about the idea that these could be used as stepping stones for other attacks. This is a real tour de force."

So in other words, like 80+% of the other exploits on web, the exploit only works if you use Internet Explorer?

From TFA:

This feat was achieved by taking advantage of the way that Internet Explorer (and other browsers) handle active scripting in the Operating System. (emphasis added)

As far as I'm aware, other browsers* don't allow "active scripting" to access the operating system unless a plug-in has been installed to do so (such as Java or Flash, and those have their own built-in restrictions).

This feat was achieved by taking advantage of the way that Internet Explorer (and other browsers) handle active scripting in the Operating System. (emphasis added)

What kind of "active scripting" is this? I can guarantee you that Firefox's JavaScript interpreter doesn't use OS-provided libraries to run the code - that would make cross-platform consistency impossible.

I'm sure that by "other browsers," the author of the article means browsers like Maxthon [maxthon.com] that are simply wrappers around IE. It's the same thing as saying that a bug in the Gecko rendering engine affects Galeon as well as Firefox. Many people (the article author included, apparently) can't distinguish betw

First of all, the hack takes advantage of the way Internet Explorer handles scripting languages, implying that Firefox/Safari/Opera users are safe. Second, I can run most Windows code on my Linux machine via Wine. If Wine doesn't have this security hole (or even XP for that matter) then its perfectly reasonable to assume that a rewrite of the affected portions of Vista will provide the fix.

To say that it's broken and can't be fixed is as much of a sure thing as saying it's secure and can't be hacked.

This week at the Black Hat Security Conference two security researchers will discuss their findings which could completely bring Windows Vista to its knees.

Mark Dowd of IBM Internet Security Systems (ISS) and Alexander Sotirov, of VMware Inc. have discovered a technique that can be used to bypass all memory protection safeguards that Microsoft built into Windows Vista. These new methods have been used to get around Vista's Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP) and other protections by loading malicious content through an active web browser. The researchers were able to load whatever content they wanted into any location they wished on a user's machine using a variety of scripting languages, such as Java, ActiveX and even.NET objects. This feat was achieved by taking advantage of the way that Internet Explorer (and other browsers) handle active scripting in the Operating System.

While this may seem like any standard security hole, other researchers say that the work is a major breakthrough and there is very little that Microsoft can do to fix the problems. These attacks work differently than other security exploits, as they aren't based on any new Windows vulnerabilities, but instead take advantage of the way Microsoft chose to guard Vista's fundamental architecture. According to Dino Dai Zovi, a popular security researcher, "the genius of this is that it's completely reusable. They have attacks that let them load chosen content to a chosen location with chosen permissions. That's completely game over."

According to Microsoft, many of the defenses added to Windows Vista (and Windows Server 2008) were added to stop all host-based attacks. For example, ASLR is meant to stop attackers from predicting key memory addresses by randomly moving a process' stack, heap and libraries. While this technique is very useful against memory corruption attacks, it would be rendered useless against Dowd and Sotirov's new method. "This stuff just takes a knife to a large part of the security mesh Microsoft built into Vista," said Dai Zovi. "If you think about the fact that.NET loads DLLs into the browser itself and then Microsoft assumes they're safe because they're.NET objects, you see that Microsoft didn't think about the idea that these could be used as stepping stones for other attacks. This is a real tour de force."

While Microsoft hasn't officially responded to the findings, Mike Reavey, group manager of the Microsoft Security Response Center, said the company has been aware of the research and is very interested to see it once it has been made public. It currently isn't known whether these exploits can be used against older Microsoft Operating Systems, such as Windows XP and Windows Server 2003, but since these techniques do not rely on any one specific vulnerability, Zovi believes that we may suddenly see many similar techniques applied to other platforms or environments. "This is not insanely technical. These two guys are capable of the really low-level technical attacks, but this is simple and reusable," Dai Zovi said. "I definitely think this will get reused soon."

These techniques are being seen as an advance that many in the security community say will have far-reaching implications not only for Microsoft, but also on how the entire technology industry thinks about attacks. Expect to be hearing more about this in the near future and possibly being faced with the prospect of your "secure" server being stripped completely naked of all its protection.

The abstract actually tells much more than the linked article, primarily what has been researched and found.

The important bit is that this is not a new exploit, it's a way to make your memory corruption (stack or heap overflow, etc) exploit, if you find one, be able to work despite Vista's additional security measures.

Similar security enhancements are present in the Linux kernel under slightly different names: Address space randomization, non-executable stack, etc. And similar tact

Ok, they have found an exploit that can lead to any malicious code being run on a host machine. That is pretty bad. The fact that this hole can be exploited using something as simple as JavaScript, even worse. However, I don't think this is exploit is something that cannot be defended against.
Anything run on the client side must be loaded on the client first, which means you do have a chance to catch it before it is loaded. Granted, on pre-compiled objects this does present more of a challenge, but scripting exploits should be easily filtered out. It would certainly slow down page rendering, but I am sure most browsers will come up with a message allowing you to bypass any pre-rendering checks...
"The page you requested contains code which, when loaded, may prove to bring your Vista operating system to it's knees. Do you wish to continue?"

I am sure most browsers will come up with a message allowing you to bypass any pre-rendering checks... "The page you requested contains code which, when loaded, may prove to bring your Vista operating system to it's knees. Do you wish to continue?"

And that will be extremely effective, right up until Joe Sixpack says, "Well if I say no, I can't get my porn." and clicks Yes.

this is what happens when you implement an extreme layer of security that can totally take over a computer, but DONT trust the computer's owners, users enough to give all power over it to them, and allow for privileged access to outside sources - be it microsoft's update servers, be it certified tech support etc.

it is only a matter of time for any malicious third party to figure out your elaborate access scheme and get control of people's computers. because if you can do it, others can do it too.

Looks to me more like a.NET and IE design flaw that could be easily fixed, than what this article is making it out to be. ABSOLUTE worst case is that it requires better authentication of the system's own code, which... shit, isn't that already part of Vista's security model? Just expand the scope. (Granted, THAT could break stuff.)

And, there's even a quick and dirty fix Microsoft could do, albeit at a possible extreme performance hit.

Sandbox.NET apps, don't trust any of the framework.

It could break OLE horribly, but not if they do it right - and how much is old-school OLE used anyway? And, for ActiveX plugins that are also used as standalone apps (such as Adobe Reader,) just fire up a second copy of the process in the sandbox.

"This stuff just takes a knife to a large part of the security mesh Microsoft built into Vista," said Dai Zovi. "If you think about the fact that.NET loads DLLs into the browser itself and then Microsoft assumes they're safe because they're.NET objects, you see that Microsoft didn't think about the idea that these could be used as stepping stones for other attacks. This is a real tour de force."

Internet Explorer (or any Common Language Runtime host) is subject to.NET's Code Access Security model. Assemblies from untrusted locations, like the Internet Zone get a very restricted set of permissions unless there is an explicit CAS policy in place to give said assemblies more permission via some form of evidence (usually a strong name or x.509 certificate).

Security is applied based on the caller, so you can't load an untrusted assembly and elevate its priviledges by simply calling a method on a trusted component on the local machine. This is not enforced by IE (or any other host) but by the runtime itself. In order to get full trust you have to get a policy in place or somehow trick the host into thinking the source is a trusted location.

Given his completely false assertion that "Microsoft assumes they're safe because they're.NET objects", you should discount everything else he has to say because he clearly has no reservations about making strong assertions about things he doesn't understand.

"using a variety of scripting languages, such as Java, ActiveX and even.NET object"

I gave up the credibility of the author just after that sentence. But the topic is of major interest regardless of the stupidity of the author. Slashdot at work, we flame the authors and discuss the topic anywho.

Too funny, not on is this article blog spam, it's plagiarised blog spam!

This comment is at the bottom of their board.

Guys: I couldn't find the editor contact info, but you've basically reposted our story from SearchSecurity.com without authorization:
http://searchsecurity.techtarget.com/news/...1324395,00.html [techtarget.com]
We'd like the excerpt removed immediately so we don't have to get the lawyers involved.
Thank you.
Eric Parizo
Editor - SearchSecurity.com
eparizo@techtarget.com

XP was vaunted as Microsoft's most secure operating system ever. And it was, for about a year. Then it went through several really horrible security incidents. Eventually the holes were patched and, even though XP will never be anyone's idea of a secure operating system, at least we know where XP's weaknesses are and how to mitigate them.

So now we're finding the Vista security holes. I'm sure there will be a stretch of security horror shows and we'll figure out how to run Vista in a semi-secure fashion. At least we'll know where the vulnerabilities are.

It's really nice running Linux when things like this come along. You can watch in a detached, slightly amused fashion. Although I'm sure our day will come.

The real problem with Windows security is that there are LOTS of programs out there that will not run unless the user is an administrator.

This is a relic of the old MS-DOS mindset, where any program could put anything anywhere on the disk that it wanted to, or mess with anything in memory that it wanted to. This attitude moved along with the coders to the Windows platform, so you have programs that try to put log files in the same directory as the executable instead of in the user's home directory. When the user calls support and asks how to fix this, the fastest way to get them off the phone is to say "run as administrator", so that's what happens.

Microsoft's part of problem is that rather than saying "Don't do that - fix your program so it can run under a normal user account", they made it so you can run as administrator, and then tried to intercept user actions that might hose things up.

This presentation was how to get around features that try to prevent exploitation of memory safety bugs [squarefree.com] 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 [wikipedia.org] or ASLR [wikipedia.org]).

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 [taossa.com].)

(I attended the Black Hat presentation but did not read the full paper [taossa.com].)

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

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.