WebKit code execution against Chrome is also likely to work (in modified form, but same basic exploit) against desktop or mobile Safari. Desktop Safari sandbox escape is likely to be completely different from MobileSafari sandbox escape. And in all three cases, the sandbox escape is the harder part.
So that logic does not explain to me why people are going after Chrome but not Safari.
I honestly don't know why it is. In particular, I don't have specific reason to believe Mac Safari's sandbox is more bulletproof than Windows Chrome's, but I guess Safari has the advantage of not being exposed to Windows kernel bugs.
Yeah, the WebKit exploit will work effectively unmodified on Safari. And the sandbox escape used against Chrome on Windows was a kernel bug in surface that can't be turned of from user-space (or really at all on Win7). Also, they softened the target quite a bit by using 32-bit Win7 for the contest, rather than 64-bit Win8 (or even 64-bit Win7).
As for why no one's targeting Safari, I think it's simple market forces at play. The iOS exploit market is established and pays very well, while the core vulnerabilities, expertise, and techniques are all shared with Safari on Mac OSX. And since Safari isn't a soft target (in no small part due to Abhishek's mass slaughter of WebKit security bugs and our bounty program), $65k just doesn't compete with the real-world exploit market.
Getting sandbox escapes from Mac Safari and iOS Safari requires completely different exploits. The code execution stage of a complete exploit could be shared, but it could also be shared with Chrome. So you'd think the same argument of iOS Safari exploit market value would apply either way.
My theory is that not much research has been done yet on breaking the WebProcess sandbox. Which makes me sad.
>Getting sandbox escapes from Mac Safari and iOS Safari requires completely different exploits.
You're focusing too narrowly on the sandbox itself. You have to consider the whole stack, and all of the surface exposed from within the sandbox. Consider the Chrome sandbox escape from yesterday, which didn't use anything specific to Chrome. It targeted part of the Windows stack that's guaranteed to be exposed to every process on the system.
