3 ms·
I wonder if this is a sandboxing issue with NaCL, which is I noticed was added (default disabled) in Chrome 11. Considering how non specific VUPEN are, I would
by phaet0n 15y ago
I wonder if this is a sandboxing issue with NaCL, which is I noticed was added (default disabled) in Chrome 11.
Considering how non specific VUPEN are, I wouldn't be surprised if they're hiding this.
- tlrobinson 15y agoSounds like it's Windows only, so I'd expect it to be related to the Windows sandboxing.
- Niten 15y agoWell clearly there are two things going on here, assuming VUPEN is on the level: 1) A remote code execution exploit in Chrome 2) A privilege elevation exploit allowing the hijacked browser process to break out of its mandatory access control jail Number 1 is of necessity a bug in Chrome itself (or a plugin). Number 2 is probably a vulnerability in the Windows sandbox, but it could instead be that they found a way to successfully attack the small part of Chrome that runs outside low integrity mode. They weren't specific as to the details. This is, again, at the very least a remote code execution hole in Chrome, and there's no fundamental reason Linux or OS X should be invulnerable to the same hole. That Chrome on Windows is less secure than on Linux or OS X would be the wrong thing to take from this; the point of this demo is that VUPEN accomplished the feat of bypassing all the security mechanisms protecting Chrome on Windows, whereas on the other platforms you have fewer of these mechanisms in the first place (no real ASLR on OS X, no Chrome sandboxing last time I checked on Linux).