Hacker News new | past | comments | ask | show | jobs | submit login
Google Chrome Zero Day CVE-2021-4102, Use after free in V8 (googleblog.com)
82 points by excerionsforte on Dec 15, 2021 | hide | past | favorite | 27 comments

IMO the most important line in that blog post is:

> Google is aware of reports that an exploit for CVE-2021-4102 exists in the wild.

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?

Why only Windows and Linux, but not macOS?

I honestly just forgot about it

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`

link [2] 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.

1. https://bugs.chromium.org/p/chromium/issues/list?can=1&q=typ...

2. https://sites.google.com/a/chromium.org/dev/Home/chromium-se...

3. https://crbug.com/1263457

4. https://crbug.com/1270658

5. https://crbug.com/1272068

6. https://crbug.com/1262080

7. https://crbug.com/1278387

On the page they state:

> 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.

This is one class of bugs that would not exist if V8 was written in Rust.

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.

This is one class of bugs that would not exist if javascript was banned.

Javascript isn't to blame: bad C++ is. It is 2021 and if you are not putting things in smart pointers, you are doing it wrong.

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.

js is the new flash. It's just as annoying, and it's the way bad people do bad things to your computer.

I cant believe you are comparing JavaScript to flash

How does this impact v8 based services, like Cloudflare Workers?

Probably not much. I remember seeing a comment from someone that works at cloudflare, saying that they could deploy changes within hours.


>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.


We patched when we were notified. And we have a pretty robust model around Workers that is meant to deal with this possibility.

Or anything running on NodeJS?

Well, if you're using an adblock with JS disabled, you may sleep well.

Luckily, Google is removing that feature.

Do … no … evil - some former corporate mantra.

Or if you're using FireFox... Which is migrating code to Rust where this sort of issue can't happen.

Unless these actors have other ways to convince you to go to their landing page :o)


Project Zero does publish writeups for Chrome bugs. https://googleprojectzero.blogspot.com/2019/04/virtually-unl... is one example.

Disclaimer: I am a Chrome developer.

Literally the very first critical security bug in this report came from a member of Project Zero.

It wouldn't be HN if someone doesn't do hot takes.

Technical briefs take time to write and publish. Give them benefit of the doubt

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact