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."
Permalink for 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