Hacker News Reader

Comment by wfh | Hacker News Reader

Code injection like this is why we have historically been unable to enable stronger process mitigations for Chrome that might improve security and stability. It's a real pity :(

https://bugs.chromium.org/p/chromium/issues/detail?id=851565...

The flag we (still) can't enable by default is

--enable-features=BrowserDynamicCodeDisabled

View on HN

Didn't Microsoft do this in the old pre-Chromium Edge? It probably would've caused more of an outcry from users if anyone actually used the old Edge as their primary browser. Personally, I feel like this is the "wrong way" to enhance browser security. Should the browser, as important as it is, behave fundamentally differently than all other processes within an OS? What about other VIPs (Very Important Programs)? Who's to decide which apps are important enough? The right way, to me, would be for the Chrome/Chromium team (along with other browser vendors) to lobby and/or work with OS vendors such as MS, Apple, Canonical, etc. to come up with sensible OS mechanisms to limit dynamic code, with appropriate user control and override options. Sure, that's a bigger undertaking and "some users will be confused" as always. But it's not worth it to me to keep shrinking what part of my personal computer I can actually control just to gain a little bit more security and stability. I want to be the one to make the choices and strike a balance that's personally right for me. So for that reason, I hope this is one feature flag you will never enable by default.

Have to agree with you. You can find some good posts (blog posts? I forget) where an MS engineer explains why the desktop on Windows is as messy as it is. The gist of it was, they did actually try basically everything else and had various types of security, but anything but having the desktop as a single security boundary (at least as far as interaction was concerned) made everything too complicated and brittle.

For this reason I highly doubt wayland will really work as intended. We're going to end up with a middle shim layer that basically acts as X11 but doesn't look like it.

Love to hear more about this?

macOS has been moving this direction for a while. To inject code into an appropriately prepared process on that platform, you will need to generally want to run as root, have to attach to the process as a debugger, and then patch it. Plus there are APIs to suspend processes at creation and such.

I'm curious if you could attempt to "fend off" such hooks into your address space?

Kind of, but it is very brittle, and you are doing something the OS does not intend you to do.

Reply on news.ycombinator.com