3 ms·
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exi
by zetafunction 8y ago
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex.
I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.
- gsich 8y agoSlightly OT: revert the ugly design introduced in Chrome 71 (or 70).
- nneonneo 8y agoSo what happened here? There's an in-the-wild exploit that's bypassing sandboxing - so there must be at least two bugs, or the sandbox isn't tight enough (which, for Chrome, would surprise the hell out of me).
- aboodman 8y agoI used to work on Chrome. There have been periodic sandbox escapes, and chained exploits that escape to userland are routinely performed at pwn2own. This is just notable because there is a live exploit in the wild.
- GordonAitchJay 8y agoThere there any public information about what the live exploit does?
- intherdfield 8y ago"The second vulnerability was in Microsoft Windows. It is a local privilege escalation in the Windows win32k.sys kernel driver that can be used as a security sandbox escape." https://security.googleblog.com/2019/03/disclosing-vulnerabilities-to-protect.html https://security.googleblog.com/2019/03/disclosing-vulnerabi...
- LukeB42 8y agoBad time to ask for browser extensions on mobile then?
- staticassertion 8y agoNaturally, but I think maybe you missed my point. I listed a subset of the things Chrome does to help mitigate the fact that C++ bugs will make it out. It's because they don't trust C++ that this is the case. What is interesting is that, in the case of the first itw exploit, the root case appears to be memory safety. That despite the many millions invested, memory safety was still what an attacker went after and managed to leverage into an exploit against users. That's all.