Earlier quoted context omitted.
?
did I stutter, nerd?
When did being a nerd become unfashionable again?
Actively exploited sandbox RCE in all Chromium versions
521–527 of 527 posts
Re: Actively exploited sandbox RCE in all Chromium versions
#522Earlier 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…
When Chromium and V8 are written in a memory-safe language then I might believe this. Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now. The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++…
I believe programmers still write in C(++) after memory safe options, in order to continue being occupied afterwards, fixing the bugs that will arise. Without criminals, police is obsolete.
Re: Actively exploited sandbox RCE in all Chromium versions
#523> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) What's the difference between "executing arbitrary code inside the sandbox via a crafted HTML page" and running whatever is in the tag?
In the script tag you only have access to JS. This allows you to escape JS and have native code execution. It is still sandboxed by os-level primitives, but it is an escalation/first step in successful exploitation.
I see, so there are certain things that arbitrary native code could try do (let's say, try to execute a certain syscall) that native code produced by the JIT compiler wouldn't normally be able to attempt?
Re: Actively exploited sandbox RCE in all Chromium versions
#524Earlier quoted context omitted.
Google is routinely buying and destroying competitors. They lower prices to kill competition en-masse. They promote their own products in search and elsewhere over paid ads. Search Engine have chicken and egg problem, you can only have a good search if enough people use it to tune the ranking and see enough search spam cases. “Just compete with a monopoly on their own field with one hand tied behind”
Every Google competitor has the problem that 40% of users won't load ads and 99% won't pay a subscription. They don't need to do anything adversarial, the greed driven mindset of the internet (ads suck, everything should be free) staves off any real competition.
That 40 percent is definitely not true in the general audience. Also they will load ads, just not all of them. Surveys ask that. Especially on mobile, and apps. Also, when we measured on our car rental site, with near perfect precision (it's absolutely not difficult), then the number was around 20%. Also, according to download statistics, there are less than half a billion people who use ad blocking browsers or other solutions on Android. And that's downloads, which is obviously inflated, even obvious from browser statistics (no not 100% of Firefox users are on Android, it's almost the opposite).
It's not nothing, but it's probably around 20%.
Also as others stated. I pay for everything, if they give me the opportunity to pay them for ad free versions. I don't see ads on my Android, and I don't use a general ad blocker on it (except my browser, but I rarely visit sites which would contain ads, and basically all of them from Hacker News). I don't use free search, email, newspapers, I pay for YouTube, and I would pay for Facebook if I would use it. I don't even use Hacker News freely, because I paid for the app which I use to not see ads, and have more features. Heck, I pay even for my torrent, because I support them.
You're in the wrong neighborhood with this sentiment. But yes, the general populace is not like this.
Re: Actively exploited sandbox RCE in all Chromium versions
#525Earlier quoted context omitted.
Every Google competitor has the problem that 40% of users won't load ads and 99% won't pay a subscription. They don't need to do anything adversarial, the greed driven mindset of the internet (ads suck, everything should be free) staves off any real competition.
That 40 percent is definitely not true in the general audience. Also they will load ads, just not all of them. Surveys ask that. Especially on mobile, and apps. Also, when we measured on our car rental site, with near perfect precision (it's absolutely not difficult), then the number was around 20%. Also, according to download statistics, there are less than half a billion people who use ad blocking browsers or other…
Good for you, now get others to do it. Definitely not the wrong neighborhood though, HN is extremely pro ad-block and every paywall link has an archive.ph link in the comments.
Hell the top story right now is about a tool for backdooring twitter...
Re: Actively exploited sandbox RCE in all Chromium versions
#526Earlier quoted context omitted.
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?
The features of HTML are still greatly limited. You can’t really create applications with just one HTML page and no client-side rendering. You can play a video, sure, but that’s not an application. You can also do magic with CSS but that’s an experimental fun thing, not a thing people actually do.
As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and that would be a SPA.
But I’m curious, what are some examples, even hypothetical, of applications consisting of one HTML page? I don’t think I’ve ever seen it.
Re: Actively exploited sandbox RCE in all Chromium versions
#527Earlier 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…
Do you have any citations for this? Not that I doubt you but I’d like to read more about it.
Yes, the V8 team released a blog when they introduced jitless mode: https://v8.dev/blog/jitless
In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%.
This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM.
Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit
We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.