[HN Gopher] From object transition to RCE in the Chrome renderer
___________________________________________________________________
From object transition to RCE in the Chrome renderer
Author : mikece
Score : 128 points
Date : 2024-08-13 15:31 UTC (7 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| olliej wrote:
| 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"
| rvz wrote:
| 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.
| nusl wrote:
| Insane. I love that these bugs are being found and fixed.
| gnyman wrote:
| 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?
| tedunangst wrote:
| Can't fall behind on those javascript benchmarks.
| mattnewton wrote:
| 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.
| soiax wrote:
| It's all renderer only RCE-s, no sandbox escape. So it doesn't
| work on your browser, only if you disable the sandbox.
| js2 wrote:
| > 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?
| bri3d wrote:
| 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...
| soiax wrote:
| 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.
| armchairhacker wrote:
| https://github.com/github/securitylab/tree/main/SecurityE
| xpl...
|
| > 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.
| helloooooooo wrote:
| 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.
| troupo wrote:
| 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
| chc4 wrote:
| 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.
| infogulch wrote:
| 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
___________________________________________________________________
(page generated 2024-08-13 23:00 UTC)