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

241–250 of 527 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#241

Post by vickychijwani »

timr wrote: post #228
varenc wrote: post #178

Earlier quoted context omitted.

I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.

That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could , but never considered if they should . See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stu…

That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.

See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.

To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.

Re: Actively exploited sandbox RCE in all Chromium versions

#242

Post by klm127 »

david_shaw wrote: post #20

Let's take a moment to talk about the monetary value of this vulnerability. According to the Chrome release page ( https://chromereleases.googleblog.com/2026/09/stable-channel... ), Google paid a researcher $1000 for ethically reporting this. The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? H…

I heard, on the podcast Darknet Diaries, that there are auctions for zero days in Argentina. This security researcher could probably have cleared a million dollars for a bug like that if they were unscrupulous. The bug bounty should absolutely be higher.

Re: Actively exploited sandbox RCE in all Chromium versions

#243

Post by creshal »

pizlonator wrote: post #146
publlus_enigma wrote: post #55

Normalising running arbitrary code delivered over the internet (in the form of JavaScript and WASM), as a necessary condition for accessing most web pages may not have been one of the best decisions we have made.

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…

> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.

It's easy to be safer, as long as performance can be sacrificed for it.

Re: Actively exploited sandbox RCE in all Chromium versions

#244

Post by noduerme »

Just outta curiosity because I can't find it at a cursory look - what exactly would be the type (coersion?) that would allow v8 to execute arbitrary code? Is this like something in post data to nodejs that terminates early and is able to run exec or something, like unto a sql injection?

Re: Actively exploited sandbox RCE in all Chromium versions

#245

Post by qlte »

drnick1 wrote: post #229
armadyl wrote: post #125

Earlier quoted context omitted.

[flagged]

The idea here is that uBlock filters the domains that may serve the malware in the first place. It basically works the same as a DNS filter.

Which you can also easily do with uBlock Origin Lite in Chrome/Chromium.

Re: Actively exploited sandbox RCE in all Chromium versions

#246

Post by xprnio »

nixon_why69 wrote: post #213
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.

That's one of the points, yes, but the black market doesn't dictate the value of the exploit to Google. A hardline bargaining position with Google would be more like "pay me what I want, or else I'll give it to all takers on the black market for maximum damage". That would be unethical and probably illegal to boot but it's a better definition of value than "1$ greater than max bid".

The value to Google - sure. But the market value of the exploit itself - the black market I think is a factor in that regardless of what Google offers.

The value of something is dictated by what _the market_ offers, and just because Google throws a lowball price because _they_ don't value it doesn't necessarily mean that the value of the exploit itself is as low as they dictate.

There will always be someone who would screw Google just for the love of the game, and if they got a better price from elsewhere, I don't see why _morality_ would really play that big of a role. It all comes down to incentives, and if Google doesn't incentivize doing the good thing enough, then someone _will_ incentivize them to do the bad thing just a bit more.

Re: Actively exploited sandbox RCE in all Chromium versions

#247

Post by literalAardvark »

ajkjk wrote: post #112
quotemstr wrote: post #110

Earlier quoted context omitted.

> Blackhat markets will always be able to pay better. ... than Google? > Selling to Google though you aren't chancing jail time. Why would you go to jail for selling a vulnerability? It's free speech.

"Aiding and Abetting" crime is also a crime. Free speech has nothing to do with it.

"this vulnerability is being sold for research purposes only and must never be used outside of a tightly controlled research sandbox"

Re: Actively exploited sandbox RCE in all Chromium versions

#248

Post by timr »

vickychijwani wrote: post #241
timr wrote: post #228

Earlier quoted context omitted.

That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could , but never considered if they should . See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stu…

That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could , but never considered if they should . See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions.…

> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.

Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.

The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.

(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)

[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.

Re: Actively exploited sandbox RCE in all Chromium versions

#249

Post by dbdr »

nixosbestos wrote: post #104
Espressosaurus wrote: post #79

Earlier quoted context omitted.

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.

I say this as someone does NOT disable JS in my main browser (because like, I have a job), but also knows a fair bit about why Firefox inside Tails now restarts in some cases... It's the classic thing. Across every gdmf metric, excluding with "true empathy", no one *gives a fuck* until it affects them, or someone within (1-3) degrees of separatation. And having broad empathy is generally a good way to get yourself la…

Is compriate a typo, a neologism? I could not find a definition.

Re: Actively exploited sandbox RCE in all Chromium versions

#250

Post by vanderZwan »

creshal wrote: post #243
pizlonator wrote: post #146

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…

> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox. It's easy to be safer, as long as performance can be sacrificed for it.

We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything.

Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.

Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.

Post reply on HN