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

471–480 of 528 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#471

Post by kccqzy »

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…

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.

Re: Actively exploited sandbox RCE in all Chromium versions

#472

Post by infinite_spin »

flatline wrote: post #383
tptacek wrote: post #92

Earlier quoted context omitted.

If the vulnerability is already being exploited in the wild --- as in, it's a vector people already know about and are tracking --- it's possibly not worth much at all. Vulnerability valuations depend heavily on the lifespan of the vulnerability; payments on black market are tranched (explicitly or less explicitly, as with "maintenance payments") based on whether they're patched. Further: a vulnerability is probably…

Isn’t the implication that the vulnerability had already been found and exploited instead of reported to Google, because its value to Google was so low? Whoever found it originally had more incentive to sell it on the grey/black market. Or is the incentive structure truly different for vulnerabilities discovered to be already in the wild?

Some exploit hunters sell strictly to the grey/black market to avoid opsec issues. If you're selling on both, you're more likely to be identified by both.

Re: Actively exploited sandbox RCE in all Chromium versions

#473

Post by ndriscoll »

quotemstr wrote: post #457
ndriscoll wrote: post #447

Earlier quoted context omitted.

It would be absurd to jail someone for accurately describing a bug on their blog or whatever. Not so much for taking money from someone who the buyer should know has no reason to be interested in buying the information. And either you know who your counterparty is, in which case you know that they are using it nefariously, or you don't know who your counterparty is, in which case you know that they are using it nefar…

Has anyone actually been charged and convicted for disclosing knowledge of a vulnerability in exchange for money with no further collusion to commit a crime?

Jeremy Jethro seems to be an example. His lawyer claimed he had no knowledge of what the exploit would be used for, and that it didn't even work, but he ultimately pled guilty to criminal conspiracy.

Re: Actively exploited sandbox RCE in all Chromium versions

#474

Post by ndriscoll »

razemio wrote: post #390
choo-t wrote: post #343

Earlier quoted context omitted.

HTML has lazy loading. There not a lot of reason to not have at least a fallback to serve your text-only content without JS.

That is true, but it is very basic and depending on the browser how it is implemented. On traffic heavy sites, which I assume gates blog is, js gives you full control over what get loaded when and at the same time enables tracking how far the user read the article and which parts he most likely skipped. I am not saying that this is good, however if you have these requirements js is a valid choice.

Basically no one has a requirement to track what someone else is looking at. In fact, if not given explicit consent by the person being tracked (like they've specifically sought you tracking it for them, e.g. marking their place), we should frankly criminalize it. Mass surveillance should result in jail time.

Re: Actively exploited sandbox RCE in all Chromium versions

#475

Post by DANmode »

grishka wrote: post #468
DANmode wrote: post #382

Earlier quoted context omitted.

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!

By that definition, Smithereen, my fediverse server software, is also an SPA, since it does what I call "ajax navigation" on desktop, so that the notifications websocket doesn't get disconnected and reconnected every time you click a link. It's technically a single page that gets most of its content replaced at runtime when you click a link, after all, right?

Yes.

Could you point out where you think the gotcha is? I can taste the tone.

Just because a bunch of engineers applied implicit meaning that didn’t exist to a very literal phrase for a few years doesn’t make it correct.

Doesn’t make webapps inherently bad.

Doesn’t make SPAs bad.

Re: Actively exploited sandbox RCE in all Chromium versions

#476

Post by DANmode »

preg_match wrote: post #453
DANmode wrote: post #449

Earlier quoted context omitted.

> it’s just a site sigh …does someone else want to finish this up?

This reply means basically nothing to me or anyone. To expand on what I mean, if the implication isn’t obvious: a SPA with no client side rendering is just a single HTML page. It’s a document, not an application. So SPA naturally implies client side rendering. The difference between a SPA and MPA isn’t the amount of pages, they both have about the same amount of logic pages. It’s about where those pages are rendered.…

Single HTML files / pages can be fully-featured, full-purpose-fulfilling applications.

> Most websites or applications are hybrids.

and some are emphatically not.

But…where were you going with that?

Re: Actively exploited sandbox RCE in all Chromium versions

#477

Post by amluto »

pizlonator wrote: post #224
Ohentis wrote: post #222

Earlier quoted context omitted.

I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.

Nah It's damn near impossible to verify that the JIT is correct. But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law. (V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)

One might argue that verifying the correctness of a JIT is basically the same problem as verifying the correctness of an entire compiler, with the added caveat that malicious inputs to the JIT are expected whereas malicious inputs to a compiler might be seen as rare.

IIRC rustc still has a couple of known soundness bugs, for example. It’s only been a few weeks since someone managed to exploit Lean, and Lean is all about formalizing things :)

Re: Actively exploited sandbox RCE in all Chromium versions

#478

Post by anonymars »

kllrnohj wrote: post #359
Gabrys1 wrote: post #276

Earlier quoted context omitted.

Knowing the vulnerability, creating an exploit might be relatively easy now that we have AI to figure the boring stuff out.

This "only" escapes the JavaScript sandbox. You still need to chain it with an escape for the process sandbox. So it's not just the boring stuff of turning a predictable crash into arbitrary execution, but also finding a second RCE vulnerability to chain this with

I'm curious now, how is it being actively exploited? Unless there is already some other exploit with which it's currently being chained?

Re: Actively exploited sandbox RCE in all Chromium versions

#479

Post by nixosbestos »

abanana wrote: post #349
dbdr wrote: post #249

Earlier quoted context omitted.

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

The end of that post came out in such a mess, it must be a typo for something - "compatriot" maybe? I like the other standout neologism in there though, I can see it in a dictionary now: astrocized - banished to outer space.

the end of that post sure did turn out a disaster and I'm not even sure what I meant. Pretty... awful.

I do know how to spell ostracized ? I'm not sure if that's what I meant? Truly a mess.

Re: Actively exploited sandbox RCE in all Chromium versions

#480

Post by xorcist »

zahlman wrote: post #317
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.

And people ask me why I complain about web pages failing to display basic content without JS. (I keep WASM and WebGL disabled in Firefox settings, too. Yes, I had another post ITT questioning why those things are any less secure than the JavaScript, given that they're supposed to be in a sandbox. But you know, defense in depth . It's insane that we're expected to put up with these grossly unnecessary risks all the ti…

Things such as WASM and WebGL should really be click-to-play, just like media files are.

I am decidedly uninterested in those features for most web pages I visit. Should they be able to spin up my CPU fan just for that I would consider it a misfeature. Just like a movie on high volume would be.

If anyone familiar with Firefox could implement that or point in the right direction, that would be most welcome.

Post reply on HN