> Google is aware of reports that an exploit for CVE-2021-4102 exists in the wild.
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?
link  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`
link  is a generic Chrome landing page
links [3-7] require Google Login (WTF?)
I gave up after that.
Edit; I actually didn't give up, I searched `https://bugs.chromium.org/p/chromium/issues/list` for the associated issue numbers with no results.
> 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.
I guess they will open up in the next few days.
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.
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.
>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.
Disclaimer: I am a Chrome developer.