Hacker News Reader

Comment by zetafunction | Hacker News Reader

> 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.

View on HN

So 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).

"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-vulnerabi...

I 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.

There there any public information about what the live exploit does?

Naturally, 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.

Bad time to ask for browser extensions on mobile then?

Slightly OT: revert the ugly design introduced in Chrome 71 (or 70).

Reply on news.ycombinator.com