Live data from Hacker News

Actively exploited sandbox RCE in all Chromium versions

nvd.nist.gov

431–440 of 528 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#431
post #397

How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet? The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains: > When a memory buff…

There's more to it than just using a memory safe language.

[deleted]

Re: Actively exploited sandbox RCE in all Chromium versions

#432

How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet? The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains: > When a memory buff…

How do you write a performant memory-safe JS JIT?

[deleted]

Re: Actively exploited sandbox RCE in all Chromium versions

#433
post #259

Earlier quoted context omitted.

I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs. That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it. (Posted from a memory safe browser - WebKit MiniBrowser compil…

In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.

The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up.

That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.

Re: Actively exploited sandbox RCE in all Chromium versions

#434

Isn't this exactly why there is a sandbox? What can the RCE actually do or obtain within the sandbox?

Yes, it says right in the CVE > allowed a remote attacker to execute arbitrary code *inside the sandbox*

So then what's the big deal? If you had JavaScript turned off it would allow code to run in the sandbox anyway?

Re: Actively exploited sandbox RCE in all Chromium versions

#435

Google has the means and ability to rewrite Chromium ; bug for bug in Rust from C++ using Astra & Fable. Same for the Linux kernel. Considering the Fermat's Last Theorem lean proof was 13MLoC and cost $300,000 it would cost $2M to rewrite Chromium & Linux in Rust going purely of combined LoC.

Why don't you do it and post it here then?

Re: Actively exploited sandbox RCE in all Chromium versions

#436

Earlier quoted context omitted.

I wouldn't consider that an SPA at all, it's just a page with an interactive element. An SPA is something that renders everything client-side and uses a generic client API to talk to the backend. A telltale sign of an SPA is that the first thing you see when you open it is some sort of loading indicator instead of the actual page you're visiting.

No, the telltale sign of a SPA is that it’s an app that’s a single fucking page, lol Please stop changing the definitions of explicit words and phrases - to anyone reading this!

Right but the implication of a SPA is that it’s an application which has many logical pages, but only one real page. The logical pages are constructed by dynamically updating the DOM using JavaScript. As opposed to navigating to a new, server-provided page.

For example, a search function. For a MPA, each search query would be a new page. For a SPA, each query is a new logical page, served on the same real page.

Technically yes, a SPA may have minimal client side rendering. But then it’s not doing much of anything at all - it’s just a site. When people say SPA, they typically mean an application with client side rendering.

Re: Actively exploited sandbox RCE in all Chromium versions

#437

Earlier quoted context omitted.

> We shouldn't look to the black market as cost discovery for these vulnerabilities We absolutely should. One of the points of bug bounties is to discourage people from selling to the black market.

The black market also prices in a risk premium for ‘this is illegal and you could go to jail for selling me this’. Google is only paying for the vulnerability; the exploit market is also paying for your mortal soul.

I'm surprised that selling knowledge is illegal? Is it really? Maybe it shouldn't be

Re: Actively exploited sandbox RCE in all Chromium versions

#438

Earlier quoted context omitted.

Because extensions especially MV2 ones only increase attack surface.

No, they don't only increase attack surface. In particular, uBo reduces attack surface a lot more than it increases it.

The only scenario in which one could possibly argue this is if the option is using MV3 uBlock Origin Lite in basic mode, where the browser handles the content blocking just reading rules from uBoL.

uBO MV2 and MV3 in any of the higher two modes objectively add more attack surface when the alternative is basic uBoL + DNS level filtering which is the most secure combination second to just DNS-only filtering.

And ultimately ad blocking is only badness enumeration which is a poor security measure to rely on, especially when the main application (Firefox) lacks proper security measures versus Chromium. It’s like the NVIDIA owners coming up with 3,000 different cable solutions to the burning connectors when its a problem with the card itself.

Re: Actively exploited sandbox RCE in all Chromium versions

#439

Earlier quoted context omitted.

The black market also prices in a risk premium for ‘this is illegal and you could go to jail for selling me this’. Google is only paying for the vulnerability; the exploit market is also paying for your mortal soul.

I'm surprised that selling knowledge is illegal? Is it really? Maybe it shouldn't be

Ah the classic programmer mistake when encountering the legal system of thinking ‘but surely this act, in and of itself, could not be considered illegal?’ When what the law criminalizes are not mere acts but actions carried out with intent and knowledge in a context.

‘Officer, you can’t arrest me for carrying a gold bar!’

‘I can if you are carrying it out of the Federal Reserve vault without permission’

Similarly:

‘Surely selling someone the knowledge that a piece of software can be hacked isn’t illegal?’

‘It is if you know or suspect that that person’s intention is to use that knowledge to commit crimes’

This would make you a ‘coconspirator’ or possibly an ‘accessory before the fact’ in any crimes they committed.

Re: Actively exploited sandbox RCE in all Chromium versions

#440

Earlier quoted context omitted.

> I chained this bug with an n-day sandbox escape and flagged the v8CTF. https://serotav.github.io/Writeups/v8/when-sorting-leads-to-...

Then what it was chained to is the real issue, not this one. The entire point of having webpages run in their own process is to prevent bugs like this one from doing worse. If you're claiming this bug is the bug that matters, you're effectively claiming they shouldn't need to run pages in their own process and just trust that there are zero bugs. No major browser does that. Not Firefox, not Safari, and not Chromium.…

Sophisticated attacks will always leverage multiple vulnerabilities. That’s why you have to think of any vulnerability holistically, not in isolation.
Post reply on HN