Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actively exploited sandbox RCE in all Chromium versions

nvd.nist.gov

Post reply on HN
Print view View original

481–490 of 527 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#481

Post by xorcist »

Espressosaurus wrote: post #79
asveikau wrote: post #67

Earlier quoted context omitted.

I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.

It became insane because nothing bloody worked without Javascript some time in the early 2010s. Like cellphones, javascript became necessary if you want to use webmail, access your bank's website, or whatever.

... or just use Google even.

Re: Actively exploited sandbox RCE in all Chromium versions

#482

Post by cageface »

preg_match wrote: post #433
ruuda wrote: post #259

Earlier quoted context omitted.

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

Do you have any citations for this? Not that I doubt you but I’d like to read more about it.

Re: Actively exploited sandbox RCE in all Chromium versions

#483

Post by sterlind »

jameshart wrote: post #412
JoshTriplett wrote: post #193

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.

There's plenty of legal gray-hat companies that will buy a bug. Zerodium is a good example though it no longer exists. These companies in turn sell to NSA, etc. maybe even foreign governments for all I know. There's very little regulation of the space iirc.

I had a friend that worked in the space. He lived an exciting life; I hope he's still alive..

Re: Actively exploited sandbox RCE in all Chromium versions

#484

Post by dwattttt »

doublerabbit wrote: post #325
dwattttt wrote: post #175

Earlier quoted context omitted.

Or disable JS altogether, and enjoy many sites working much quicker. Many others fail & need to be selectively allowed, but it's been worth it.

If by quicker you mean blank content, I'll agree, it is worth it.

Actually thinking back, I get _more_ content, because there's a notable number of access screens that just don't function with JS off, leaving the whole article available.

Re: Actively exploited sandbox RCE in all Chromium versions

#485

Post by gsnedders »

kccqzy wrote: post #471
preg_match wrote: post #433

Earlier quoted context omitted.

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

I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.

This hasn’t been true in over a decade.

Re: Actively exploited sandbox RCE in all Chromium versions

#486

Post by odyssey7 »

mccr8 wrote: post #406
odyssey7 wrote: post #374

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…

JIT bugs like this are not easily solved simply by writing a browser in a typesafe language. Here's the commit that fixes this issue: https://chromium.googlesource.com/v8/v8/+/e0562d87ad9c17042b...

If including JIT in a system renders its developer incapable of guaranteeing memory safety, then perhaps that developer’s approach to JIT is not yet mature enough to ethically distribute to non-technical consumers who are not positioned to evaluate that their security is being traded off by the developer on their behalf.

We’re past the era where security issues emanating from memory-unsafe code were tolerated due to being unavoidable — continuing to expose your software’s users to them in this present day and age is simply a choice.

Re: Actively exploited sandbox RCE in all Chromium versions

#487

Post by turpentine »

no-name-here wrote: post #290

Is the HN title true that it affects all "all Chromium versions"? Per OP link, it only affects Chrome versions prior to .82; .82 was released as stable 2 days ago. [1] (HN title also does not match the original title, which is the CVE ID -- not particularly intuitive.) [1] https://chromereleases.googleblog.com/2026/09/stable-channel...

Ubuntu still considers 152.0.7977.64 stable.

Re: Actively exploited sandbox RCE in all Chromium versions

#488

Post by DANmode »

realusername wrote: post #451
DANmode wrote: post #450

Earlier quoted context omitted.

Plenty of app usecases don’t need to “scale” - immediately or ever!

That's a good point but you never know that from the start, "this app won't scale well" is a hard sell for a new project in my opinion

Especially today, single-user stuff, especially in categories of things like health,

especially when you’re writing your own stuff,

that’s when you know from the start that scaling doesn’t matter! =]

Related, and more powerful than my comments in this thread are going to be:

https://www.robinsloan.com/notes/home-cooked-app/

Re: Actively exploited sandbox RCE in all Chromium versions

#489

Post by turpentine »

odyssey7 wrote: post #342

It’s really a shame that my engineering school requires me to use Google Chrome because their Honorlock browser extension[1] requires Google Chrome. You would think that an engineering school would be wiser than to require their students use a specific web browser that’s tied to a specific vendor. [1] https://app.honorlock.com/install/extension

> You would think that an engineering school would be wiser...

Schools are a business run by administrative staff who make purchasing decisions to solve business problems. Schools love to reduce billable teaching hours through online coursework, which invites academic dishonesty from students, and paying for honorlock is a way to achieve that reduction in expenditure, rather than paying tutors to supervise exams in person.

Re: Actively exploited sandbox RCE in all Chromium versions

#490

Post by eru »

muvlon wrote: post #380
eru wrote: post #61

Earlier quoted context omitted.

In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.

What would that even look like? What is "benign"? The browser environment already has pretty strict rules for what the JS can do. It's not allowed to read your files, see your webcam without permission, know about other tabs or windows etc. The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "ben…

To give an example that goes beyond what you already suggested:

You can prove that your code terminates (or rather responds to events in a finite time, even if the event loop itself runs forever.) Or you can even prove that your code reacts quickly, ie within some time limit. You can also prove memory limits.

> The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?

Defense in depth. And you can have competing implementations relatively easily for this, and another way to find and report bugs. Especially if the verifier is open source.

The verifier itself can be pretty simple: it's the prover that's complicated and needs smarts, but that's being run on the author's computer, not in the user's browser.

Post reply on HN