From object transition to RCE in the Chrome renderer | Hacker News Reader

From object transition to RCE in the Chrome renderer

github.blog

177 pointsmikece33 comments

I really like these super detailed exploit breakdowns, and how they touch on circumventing the mitigations (largely because I wish people would understand that mitigations are just that - they make it harder to exploit a bug, not impossible).

Obviously ASLR specifically is pretty weak these days, but the idea is the same (and also it’s still important - this is very much along the lines of “I have seatbelts why do I need airbags”

When did Chrome go from the most secure browser to there is a exploit-chain giving RCE by visiting a malicious website every second month? (Last one I recall was CVE-2024-4761 and -4671)..

Or maybe it was never really secure and it was just good marketing?

Can't fall behind on those javascript benchmarks.

even that was marketing

The bar for chrome was IE at the time, and it beat that.

I think it’s also partly Google’s very open culture on CVEs that means they are discovered and reported on promptly. It’s difficult to tell how much it’s just increases awareness that browsers are full of holes and whether the holes are increasing in size/frequency tbh.

> The bar for chrome was IE at the time, and it beat that.

I would say there were three trends that happened at the same time that really made a difference:

- People now actually update their web browser, and yes, started to ignore the browser vendor that wasn't shipping them (IE). Driveby download exploits started to disappear.

- Flash and Java went from enabled by default to prompt-first. Flash was later abandoned, and IcedTea-Web / Java Web Start had its core functionality gutted in later Java versions.

- No support for ActiveX at all, unless you wanted to go for IE Frame (Chrome and IE tabs under a Chrome interface) or Chrome Frame (IE and Chrome tabs under an IE interface), which quickly faded into corporate Intranet obscurity

All three saved us from a much worse future.

It's all renderer only RCE-s, no sandbox escape. So it doesn't work on your browser, only if you disable the sandbox.

> I then leverage this to achieve arbitrary memory read and write outside of the v8 heap sandbox, and in turn arbitrary code execution in the Chrome renderer process.

So the code is running in a process that runs as the same user running the browser. That's no longer much of a sandbox and you're now relying on the OS to protect your data, right?

No. You're relying on the OS's sandboxing features, which are much, much more granular than just "the same user running the browser."

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...

No. There is a reason the author keeps repeating "arbitrary code execution in the Chrome renderer process." Because it's there, not in the browser process.

https://github.com/github/securitylab/tree/main/SecurityExpl...

> If successful, on Ubuntu 22.04, it should call launch xcalc when calc.html is opened in Chrome.

Then how does this work? It doesn't look like the provided build flags disable any sandbox that the distributed build doesn't.

You can disable it runtime, with --no-sandbox command line option.

It is the most secure browser. The lifetime of these kinds of bugs is generally a few weeks to perhaps 2 months. With a high churn codebase, these things just happen. There is a lot of ongoing work to mitigate the impact of renderer bugs, such as the V8 heap sandbox.

As others said, they are quite open about vulnerabilities and CVEs.

However, Chrome is an operating system unto itself. It's more than 40 million lines of code comprising of complex intertwined systems. It's a miracle there are so few CVEs

Chrome has the most vulnerabilities because it's the largest browser by market share by a mile, and so has the greatest number of eyes on it. You also can't extrapolate "it was never really secure" from that: practically all software has bugs, especially multi-million line codebases like Chrome. Relative to the average C++ program Chrome is exceedingly secure, and likewise Chrome has been constantly on the cutting edge of introducing new security mitigations. "Is it secure" is not a binary property.

It can be a binary property if you define security as a proof of absence of runtime errors which is possible to achieve today.

This isn’t really possible to achieve.

It's possible. You can prove absence of runtime errors with Ada/SPARK (which is using theorem provers).

Google trying to cram everything including the kitchen sink into chrome probably doesn't help here.

Who in their right mind thinks it makes sense to have a desktop screen sharing system... built into a browser?

It makes sense once you realise that Chrome and Google benefit from increasing the complexity of web browsers. It means that new browsers cannot feasibly compete. It's basically an arms race of "how much mental shit can we throw in there"?

I understand why they do it (I think it's probably more about pushing the idea of a browser as the thing people use for everything than competition with other browsers TBH), but I definitely wouldn't say it "makes sense".

Just used in few days ago an it was very practical to use it instead of downloading some third party software. Since video conferencing apps are web-based it makes sense.

Haven't seen such a detailed writeup like this one in a while. What a find.

Goes to show the level of sophistication and technical skill of this RCE rabbit whole.

Well done.

Google is taking hostile actions against adblockers (and has attempted to do so for years now). Chrome using too much memory is a meme among normies at this point. It's hard to say whether Chrome is less secure than competitors or if its exploits just get more publicity; clearly it was better than the competition at its inception, and clearly it could be better today.

At what point is replacement the right answer?

There are some promising browser engines in development right now: Servo / Verso, and Ladybird. Some discussions from the past few days:

Verso – Web browser built on top of the Servo web engine | 806 points | 319 comments | https://news.ycombinator.com/item?id=41215727

Ladybird browser to start using Swift language this fall | 200 points | 196 comments | https://news.ycombinator.com/item?id=41208836

Insane. I love that these bugs are being found and fixed.

- 21 security fixes were addressed in 126.0.6478.56/57( Windows, Mac)

- $168615 awarded to security researchers and unknown $X in TBD bounties

I sure hope they're refactoring parts of the codebase to leverage memory-safe languages.

Would have been better to be plain and simple C99 coded.

rust, since its syntax has the same toxic complexity than c++, not really worth it.

But the real solution is to restore noscript/basic (x)html where reasonable.

I don't think any programming language would help with the huge surface area present in a modern browser. What really needs to happen is that the web browser needs to be obsoleted by something simpler and better. Something that at least has the chance of being reasonably secure.

People want "one big program" that can do everything on the web. Doesn't matter that it's a stupid idea. We still want it.

They never have wanted that, they were forced into that, it was decided for them by big tech.

That said, you perfectly can have a big program, actually one window with tabs (chromebooks), handling various network protocols (URLs are nice, irc:// etc), or system interaction.

Yep, this is what I was implying with the restoration of noscript/basic (x)html. Nearly all online services can be provided with noscript/basic (x)html, like many were before being broken by script kiddies and nasty business men who needed to do business at all cost (aka breaking simple and stable in time protocols which were having the job done). Those last are nasty pieces of work, and are seriously toxic for humanity as a whole.

That said, I gave some thoughts of that thing which would be simpler and stable in time: a light javascript engine with very basic OS functions, and I mean very basic (namely _NOT_ google AMP).

Namely, a dynamic viewport into a "framebuffer" surface 10bits RGB, and very, _VERY_, few "acceleration objects" (i18n text shapper/video decoder/blitter/network/etc), fully event based with support of multi-threading (explicit locking only, and very basic sync primitives). Namely RIP CSS and 99.99% of the insanity which became the "scripted DOM". On low-end hardware, this may be too slow to render, so this would have to be tested, we are talking heavy R&D with an outcome being very likely a failure.

I was lurking on quickjs from Mr. Bellard friends (ffmpeg/qemu/tinycc/etc) while giving some thoughs about this.

There is some kind of alternative beyond restoring noscript/basic (x)html portals (with proper network protection, ofc) though: regulation on the network protocols of critical services: namely regulated publishing of versioned (but very stable in time), straight to the point, simpler to parse than basic (x)html, noscript, rigorously defined protocols, basically a RFC (txt format), easily and readily availably on internet ("HTTP curl" would download it, and search engines would index this document and list it).

For instance, in my city there is a public service of electric bikes, the network protocol should be public (with the features I did describe above) to allow all past/present/future/small/big/etc platforms to work, instead of _ONLY_ google and apple apps (or their web engines... which is no better). For instance HTTP with a very simple json based format.

The main threats are those guys... you know those who would push over-complicated and badly defined network protocols and delirious dependencies (ultra complex parser? gigantic script engine?)

For the "frame buffer" surface, I was actually thinking 64bits per pixel, 16bits per components ARGB (aka completely overkill for a good and long time in theory).

They've been working on adding Rust support to Chromium for a while now, mainly focused on how to make interacting between the C++ and Rust easier. As opposed to your down voters, the people who actually work on the code base seem to understand the benefits.

https://security.googleblog.com/2023/01/supporting-use-of-ru...

https://chromium.googlesource.com/chromium/src/+/refs/heads/...

https://github.com/google/crubit

Reply on news.ycombinator.com