Earlier quoted context omitted.
That’s not how things are valued. That’s moreso how the absence of something is valued.
Go without air for a few minutes and you’ll die, and yet they give the stuff away for free.
Stop giving them ideas.
Actively exploited sandbox RCE in all Chromium versions
261–270 of 527 posts
Re: Actively exploited sandbox RCE in all Chromium versions
#262Not to downplay the severity (patch your browsers!), but there have been 5-10 actively-exploited V8 type confusion vulnerabilities in the last year. I'd be curious if this one blew up because it was the only one that was posted, or if it barely crossed some line in the collective consciousness this time around.
I think it's the first one where the Chrome version fixing it has no Manifest V2 support at all.
Re: Actively exploited sandbox RCE in all Chromium versions
#263Earlier 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…
The problem is not url management. That should happen just once or twice during the life cycle of a page. If it takes 0.1ms or 1ms doesn't have any impact on the usability.
One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to render. I could solve that in JavaScript. I had to, really.
So, as practically always, the problems stem from a combination of factors, and bad programming definitely is one of them.
Re: Actively exploited sandbox RCE in all Chromium versions
#264Normalising 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.
That's basically the comment I was just going to write but you made me not need to.
We need simpler protocols and formats, especially those that are used over the internet. I want everyone to really start fighting for this.
I always use a browser that doesn't run any scripts (w3m) for both this reason and others. It hurts when I see websites that don't work without js. A bit funny though that this page is one of them so I was not able to read it.
Re: Actively exploited sandbox RCE in all Chromium versions
#265Is this known to be exploitable in any Electron apps, and specifically VSCode extensions?
Re: Actively exploited sandbox RCE in all Chromium versions
#266I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
Don't. Garbage Collector hurts your memory
Re: Actively exploited sandbox RCE in all Chromium versions
#267Re: Actively exploited sandbox RCE in all Chromium versions
#268Earlier quoted context omitted.
How much money is lost by consumers/businesses for every hour the vulnerability is exploited in the wild with no patch?
The value of the report is dependent on the scarcity of the knowledge. If anybody can report it, the bid goes down.
How do you figure? The value of the report is, ethics aside, the same as the value of exploiting it. Doesn’t matter if I can conceive of it, it matters if I can exploit it.
Re: Actively exploited sandbox RCE in all Chromium versions
#269Earlier 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…
> See most of the ecosystem around React, for reference. I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out , it would then call my…
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
Re: Actively exploited sandbox RCE in all Chromium versions
#270> Type confusion in V8 Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
> Unfortunately, it breaks about 30% of the web.
Only 30?