Indeed. At one point this was a bigger deal, now it seems that this is the new normal.
Chrome bought a good decade or so of security for itself by leveraging sandboxing, but it seems that attackers have gotten their bearings, so here we are.
I'm curious though. 4102 is a v8 vulnerability. That shouldn't be sufficient to take over a computer. I wonder if there's another 0day for Windows/Linux that it's being paired with?
Pretty useless page if you are interested in details;
link [1] is a search query for `type:bug-security os=Android,ios,linux,mac,windows,all,chrome label:Release-2-M96` which returns no result from `bugs.chromium.org`
> Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.
Unlikely - JS engines do a lot of things that are inherently unsafe - pretty much anything related to garbage collection isn’t doable outside of unsafe{} blocks in rust, which as you might guess are unsafe.
I can’t speak for V8, but the majority of UaF in JSC have been due to GC bugs collecting objects early. Being in C++ isn’t relevant.
Many other bugs are in things that are doing absurd memory manipulation needed for execution speed of common primitives. The rust implementation of these would also necessarily be unsafe.
I'd be interested in hearing from others on this, but typically the way that "inherently unsafe Thing" gets done in rust is that you have an unsafe layer wrapped in a safe layer.
The problem is obviously building the safe layer. Sometimes that's really hard. There are obvious examples already in Rust - like creating a safe API over scoped threads, or io_uring, ghostcells, etc. Some things may not be representable using only safe code in Rust, with no overhead.
Another relevant thing you can't really safely express is FFI. That would be relevant here since there's this VM boundary.
And then you get JITs, which also have tons of security issues.
Idk, I'd be curious to read about this if there are any papers. Maybe the wasm people are thinking about this?
Certainly it's not unreasonable to say that a memory safe JIT'd VM is going to be tough make memory safe.
If it’s a bug in V8 it’s likely either GC or codegen, no amount of smart pointers gets you to being completely safe, but the same applies to all the “safe” languages as well.
Probably not much. I remember seeing a comment from someone that works at cloudflare, saying that they could deploy changes within hours.
edit:
>Fortunately, we have an advantage here, in that we directly control the machines on which our system runs. We have automated almost our entire build and release process, so the moment a V8 patch is published, our systems automatically build a new release of the Workers Runtime and, after one-click sign-off from the necessary (human) reviewers, automatically push that release out to production.
>As a result, our patch gap is now under 24 hours. A patch published by V8's team in Munich during their work day will usually be in production before the end of our work day in the US.
> Google is aware of reports that an exploit for CVE-2021-4102 exists in the wild.