Linked by Amjith Ramanujam on Fri 8th Aug 2008 13:14 UTC
Windows This week at the Black Hat Security Conference two security researchers will discuss their findings which could completely bring Windows Vista to its knees. 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."
Thread beginning with comment 326313
To read all comments associated with this story, please click here.
Summary of "exploit"
by vaette on Sat 9th Aug 2008 12:43 UTC
vaette
Member since:
2008-08-09

Ok, there is a lot of confusion what this "exploit" actually entails, despite the paper actually being reasonably clear. I'll summarize the paper though:

Vista introduced several new protections against memory corruption attacks. Notice that this is not the whole of Vista security, it is just one aspect that it intended to trip up exploit makers as much as possible. The following are the ones considered in the paper:

* DEP. Making stack/heap pages non-executable. Classic page-table approach, makes executable pages non-writable by default, and writable pages non-executable by default.
* GS. Stack protection, inserts "canaries" in the stack frame, so that if a memory overrun occurs the canary is destroyed before the overrun can get to a return address (the return address being the classical overrun target; just overwrite the return with wherever the exploit wants to go).
* SafeSEH. Exception handler validation. Makes the compiler generate a list of allowed exception handlers for each executable. Whenever an exception is thrown the runtime checks that the handler is one of the allowed ones. Prevents exploits from overwriting the handler addresses with a location it wants to go to.
* ASLR. Address space layout randomization. Places the stack/heap/code sections at slightly random locations to make it hard to the attackers to know where they need to get exploits to jump. Since the exploits are often only able to jump to one arbitrary memory location the attacker wants to know how to get there.

Several of these are also available on Linux and OSX (in varying degrees), and everything in the paper applies equally to them (more greatly if anything as they do not have the benefit of sandboxed IE in Vista).

The exploit needs to do two things to be effective, it needs to upload a lump of code into an executable section in the system, and it needs to jump to it. ASLR and DEP tries to make it harder to upload the code in a useful place, GS and SafeSEH protects against two ways to try to fool the system to jump there. The paper outlines the following methods to defeat these:

The most interesting part is how they defeat ASLR; a very large NOP slide (http://en.wikipedia.org/wiki/NOP_slide). Simply write several megabytes of exploit code which one can jump into at just about any position and get to run. This multimegabyte lump of code can be written in JavaScript, a Java applet, a flash movie or a .NET applet. Then the exploit jumps to the roughly right region, and as it doesn't matter that ASLR has moved the target around one can still hit it.

Core IE and .NET runs with DEP though, so this will not work immediately. As it happens though, Flash and Java both leave data pages executable, so DEP is circumvented thanks to those plugins. The paper also outlines a way to fool .NET binaries to load without DEP (through a special combination of PE header flags), which is quite interesting. That is the only real bug/mistake noted in the paper, and I would suspect that it will get fixed.

Finally, getting the jump to go into such a set up section means circumventing either GS or SafeSEH. SafeSEH is trivial in IE, as it has to be disabled as soon as a plugin without SafeSEH is loaded, and both Flash and Java take care of that. GS is not strictly speaking defeated in the paper, but rather they look for holes in the heuristics. GS is after all not absolute, just a tricky filter to get exploits through.

With all that said: All techniques in this paper apply equally to all browsers and operating systems. The fact that it mentions Vista specifically is only because it has such a comprehensive set of techniques to consider. The paper does correctly and interestingly note that due to browsers being such extensible and dynamic programs it is hard to make protections work well, as the chain is only as strong as the weakest link. Which rings true on all systems.

The real short summary though: Flash/Java plugins can be used to circumvent Microsoft protection techniques as they don't use them. This still need a critical exploit to be useful, and those are still made harder by GS and friends. Even then the IE UAC sandbox is not breached by anything listed in this paper.

Reply Score: 5

RE: Summary of "exploit"
by PlatformAgnostic on Sat 9th Aug 2008 16:05 in reply to "Summary of "exploit""
PlatformAgnostic Member since:
2006-01-02

Thanks for the summary. Is the actual paper publicly available?

Reply Parent Score: 2

RE[2]: Summary of "exploit"
by vaette on Sat 9th Aug 2008 21:19 in reply to "RE: Summary of "exploit""
vaette Member since:
2008-08-09

It was linked above as http://taossa.com/archive/bh08sotirovdowd.pdf

At the time I could fetch it and read it, but now it seems inaccessible. In fact, it appeared inaccessible again when I wrote the post, so I might have missed some details typing out of memory. I think the summary should be a reasonably accurate reflection of the content however.

The whole thing is pretty interesting all told, as it sheds some light on the hurdles of adding extra security layers to such an as sprawling application platform as a web-browser. It doesn't really invalidate any of the techniques that Microsoft employs in Vista (ASLR seems rather damaged by it, but the NOP slide really needs the DEP circumvention to be practical, and ASLR after all prevents attempts to jump to pre-existing code), but it does illustrate what may be a wider problem for applications of this nature.

A bit unfortunate really that the article is so vague and sensationalistic, as it could have been an interesting topic of discussion but ended up a bit flamebaitish.

Reply Parent Score: 1

RE: Summary of "exploit"
by Windows Sucks on Sat 9th Aug 2008 16:20 in reply to "Summary of "exploit""
Windows Sucks Member since:
2005-11-10

The interesting this about this problem is that it seems that IE is the biggest problem, along with .NET and Active X (All Microsoft products)

Does not focus on Java and Flash etc.

So that said, does this mean that MS also does not put the same security on their own products?? As Java, Flash etc does not use the security built in?

Reply Parent Score: 2

RE[2]: Summary of "exploit"
by vaette on Sat 9th Aug 2008 21:12 in reply to "RE: Summary of "exploit""
vaette Member since:
2008-08-09

IE is not the problem, not only will the same techniques work against Firefox, Opera and Safari, they will if anything work better as those don't present the additional hurdle of the IE UAC sandbox.

This has nothing to do with ActiveX, any other plugin architecture would be just as problematic. Being able to fool .NET to not run with a poor DEP setup with a specially crafted header is a problem (probably a bug) though, true enough. Still, as Flash and Java never sets up secure page settings it doesn't really make much difference for now.

Reply Parent Score: 1