More details on the Pwn2Own Flash flaw that won the Vista machine
Summary: So, I've been pretty surprised by the response to the discussion of the Flash flaw that allowed the Vista machine to be compromised in the Pwn2Own contest.
So, I've been pretty surprised by the response to the discussion of the Flash flaw that allowed the Vista machine to be compromised in the Pwn2Own contest. I'm working on getting an interview with Alexander Sotirov and Shane Macaulay (see image, courtesy of ZDI's official site) to discuss the issue, but in the meantime, I think we can make some reasonable assumptions from the details that have been released in an InfoWorld article:
Macaulay, who was a co-winner of last year's hacking contest, needed a few hacking tricks courtesy of VMware researcher Alexander Sotirov to make his bug work. That's because Macaulay hadn't been expecting to attack the Service Pack 1 version of Vista, which comes with additional security measures...
For those who aren't familiar with Sotirov, he's of the Javascript Fung Shui fame, which is basically a new method of heap spraying that allows the exploit code to have a predictable target address where it will be located in the heap. So they team up and get to work:
Under contest rules, Macaulay and Miller aren't allowed to divulge specific details about their bugs until they are patched, but Macaulay said the flaw that he exploited was a cross-platform bug that took advantage of Java to circumvent Vista's security.
Hmmm... does this sound familiar to anyone? See my posts (part 1 here and part 2 here) on the flaws that John Heasman spoke of in Java which require it to turn off features like DEP in operating systems that provide these protections. So my guess, and I feel it is an educated one (of course time will tell), is that Sotirov helped out by providing some additional hacker ninjitsu by helping Macaulay load this Flash attack through a Java Applet, thus turning off any DEP protections the operating system provides. Heck, I wouldn't even be surprised if he used the applet to do some fancy heap spraying to load the shellcode from the heap. The article continues:
"The flaw is in something else, but the inherent nature of Java allowed us to get around the protections that Microsoft had in place," he (Macaulay) said in an interview shortly after he claimed his prize Friday. "This could affect Linux or Mac OS X."
Macaulay said he chose to work on Vista because he had done contract work for Microsoft in the past and was more familiar with its products.
Aha, so there is your story right there, this flaw could've worked on any of the systems; however, the contest rules state that the same exploit can only be used to compromise one machine (see rule #2 from the cansecwest.com web page which states "You can't use the same vulnerability to claim more than one box, if it is a cross-platform issue."), and Macaulay used Vista because it was what he was more familiar with.
So I guess we can end the OS wars about who's is better. Perhaps I could just put up a poll so we could vote on it and get that all over and done with. So now, we should be pointing the finger at Adobe for allowing this flaw... or wait a minute, should we be pointing it at Sun since it doesn't play nice with DEP?
-Nate
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Or should we blame Microsoft
That would be the ABMer's excuse anyway.
NBMer would say that Adobe is at fault for not putting the man power behind their development cycle and getting with the program in time.
RE: Microsoft
Actually, I agree, it would've been nice if we had those protections sooner, and it would be nice if Microsoft could force everyone to opt-in.
-Nate
MS has had DEP support since XP SP2
RE: MS has had DEP since XP SP 2
Nate
To sum up the battle in a few lines
[b]Developers:[/b] Wait, that's not enough time, We won't be ready.
[b]Microsoft:[/b] Too bad.
[b]Developers:[/b] Fine be that way, we will just make you look bad
[b]End Users:[/b] Our Apps won't work on this beta!!!! Make them work
[b]Developers:[/b] This is all Microsoft's fault
[b]End Users:[/b] Microsoft, fix this or we will complain more
[b]Microsoft:[/b] Alright, developers can have their way.
Nice summation (nt)
RE:
Forgot last 2 steps...
<p><b>Developers:</b> This is all Microsoft's fault for not requiring DEP.</p>
Sorry not this time.
So, this particular bug can't be laid at Microsoft's feet unless you want to fault them for supporting java's virtual engine. And if you do that you need to blame every graphical user interface based operating system capable of browsing the web.
Oh, NO! I have to disable Java [i]AGAIN[/i]?
I have it always disabled
Point at Sun for allowing Java to bypass DEP protection.
RE: Point to sun
-Nate
"Turning off DEP"????
Suppose you run a JVM as a non-privileged user on a DEP-enabled machine: Does the JVM still disable DEP?
No
I don't know the details of the JVM attack, but it probably exploits the fact that a JVM host process always has at least some memory pages that are both writable and executable, whereas a normal native code process only has pages that are executable but nonwritable (code) and writable but nonexecutable (data).
RE: No
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6545701
Something's not right...
Not really...
If the JVM on Windows can't work with DEP as Nate says, then that's only because it has a bug, probably due to their programmers' incorrect assumption that data pages are executable by default.
You misunderstood me...
However, no program running without elevated privileges can change the DEP settings, so Zogg's fears are unwarranted. The JVM can't and doesn't make any attempt to turn off DEP. It simply has a bug that requires the administrator to turn off DEP for the host process (IE in this case).
This contest had only one loser.