I know this is a bit a pet peeve of mine, (and not a very popular opinion) but I think the browsers are doing too much, and WebAudio is a very good example of that.

Instead of standardizing something low-level to input/output audio and query the hardware, like an OS; it standardizes soooo many things and filters, including downmixers, panners, quadfilters and Convolution (for reverbs); which is where the issue is in this exploit.

The resulting complexity is huge, almost impossible to implement correctly in a cross-browser way, and a lot more code in C/C++ is written.

I do advocate simpler APIs for audio, low-level, and let JS or Wasm do the filtering, using the JS sandboxing model.

And, of course, this does not apply only to WebAudio, but I think WebAudio is a good symptom.

It's not just you. Browsers are systems-within-systems. They're gigantic, illustrated by the fact that the number of implementations that are well maintained can be counted on one hand. A lot of people take issue with that.

The Web platform is now so gigantic and complex that even Microsoft has decided it's impossible to write a browser!

Or Microsoft did a back of the napkin calculation and realised that the potential increase in user base for Microsoft products wasn’t worth the money.

Their users are already on Windows and Microsoft already has telemetry on them. And we’re talking about the browser guts and not the surface, which is where most of UX lives. But none of this means that Microsoft is browser incompetent.

MacOS’s media framework uses sandboxes so even if media gets exploited it wouldn’t be able to write to disk or launch processes like in this example.

There’s really no excuses in this case for WebAudio, of all things, to be able to write to disk. And it’s dubious that Chrome should be able to launch any processes outside of the few specific child jobs it needs for process isolation.

We need something like `pledge` from BSD available across all platforms. Would mitigate quite a few of these exploits. Though, shipping good SELinux policy could solve the problem as well, maybe even better.

wasm is only a new phenomenon and those APIs were designed without wasm in mind. Note that wasm is also slower and thus more resource (battery) consuming than a native C++ implementation. Also, Chrome is already adding audioworklets to WebAudio so it will become customizeable. Last but not least, browsers are at least a central place that can be patched. Compare this to a possible future where vulnerable wasm libraries are being used in web apps, allowing third parties to run cross site wasm based exploits. Websites can't even switch off sms based 2fA, would you expect them to keep their wasm libraries up to date?

> Note that wasm is also slower and thus more resource (battery) consuming than a native C++ implementation.

My tests for codecs is now around 20% slower than native code, for the naive implementation. And SIMD.wasm helps a lot.

Long story short, WASM must be removed from browsers before it reaches wider adoption. And along with other completely unneeded APIs.

Parties opposing that must be expelled from standard bodies.

P.S. Just look at completely outrageous effort to push payment APIs into the browser and stuff they want to bundle along https://www.w3.org/2019/09/15-wpwg-minutes.html

Those are two genuinely useful things, without the hardware API issues of the others.

No.

I disagree. By having the browser implement these features we gain security. Chrome's sandbox is extremely powerful, and they can isolate and restrict all of those features you're describing very deliberately, in a way that a more generalized OS provided tool may not be able to.

> I disagree. By having the browser implement these features we gain security.

This is the opposite: this FFT and convolution code is in C++, and therefore OUTSIDE of the JS sandbox.

My point is that there should be a minimum in C++ and MORE inside the JS sandbox.

Browsers sandbox more than just the javascript VM/ renderer.

Obviously not the webaudio part, seeing this exploit.

There was likely a sandbox escape.

I completely disagree. I think we've already seen with the JS-framework-of-the-day culture, flash, java applets and whatnot what happens when a browser doesn't provide the right level of abstraction for the developers. The developer tools are still years behind what developers need and if the browser doesn't provide them, a million npm dependencies will.

Where did you see the reference to webaudio? Link to any other relevant details about the vulnerability, specifically?

If you follow the link, you'll see it is in the webaudio convolver.

The issue is that a lot of the use cases for the processes you mention have soft real time requirements where GC pauses are unacceptable, and the underlying OS's have differing world views when it comes to dealing with audio (even on the same OS, there may be different driver APIs with fundamentally different approaches to audio I/O!).

So having a simple audio API + ability to do pro-audio like things in JS is not really possible in a browser. They have to expose a complex framework with a nuanced API to the underlying engine to make some of this stuff even possible in a web browser.

> So having a simple audio API + ability to do pro-audio like things in JS is not really possible in a browser.

Absolutely not: wasm does not have GC pauses.

You'd be right about Firefox or IE, but that's not the case with Chrome, because Chromium OS is a thing. Google is building an OS, not just a browser.

You are completely missing the point: they should do less in C/C++ and more in JS/TS/Wasm.

I wholly agree with you. Somebody must push back on companies trying to push useless APIs

> "The exploit used a race condition bug between two threads due to missing proper synchronization between them. It gives an attacker a Use-After-Free (UaF) condition that is very dangerous because it can lead to code execution scenarios"

This is why C++ needs to be retired; and why we need to use safer languages. Not even Google can write safe C++. Thankfully Mozilla have already realised this.

> This is why C++ needs to be retired; and why we need to use safer languages.

These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.

But not in Rust. Go isn't exactly a bastion of safety. It's memory safe due to the GC, but it has a weak type system, so logic bugs are not well guarded against.

> It's memory safe due to the GC

That gets debatable as soon as you start using concurrency, like I said. There are idiomatic patterns in concurrent Go that are very much not safe.

What do you mean?

It has a GC, right? So use-after-free is impossible, no?

On the other hand, Go code is a lot easier to audit.

The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

Disagree on this. In Rust I can read most of the information I need to know straight from the function signatures. In Go I have to go through every line of code (and there are often a lot of lines due to Go's lack of expressive power).

In Rust code I audit, I typically have to jump through multiple layers of abstraction and cleverness, while Go code is straight forward and boring.

I guess it's a matter of preference. If something is abstracted, then you only have to audit it once (and often you can count on someone else having audited it). With Go code, everything is new and unique, so there are a lot more opportunities to introduce bugs.

Not to be argumentative, honestly, that sound pretty laughable if you don't have an equivalent of an algebraic effect system (or similar).

A "function" in Rust can do a whole bunch of stuff that is not signaled by its type signature.

Mutability / immutability is in the function signatures, and that goes a long way. It's not as good as an effect system of course. But along with global variables barely being a thing in Rust, it goes a long way to cutting out the common course of bugs.

Rust is not safer than Go, people thinking otherwise misunderstand borrow checker vs GC.

Furthermore you're talking about memory safety vs business logic bugs, two different things.

Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior.

I haven't heard of this causing a problem in practice, though.

I never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption.

Please give us a code example.

Here's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace

Here you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.

Yes, not synchronizing a slice can lead to memory corruption in Go.

Slice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it.

(I haven't seen this happen, though.)

Are all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.

Unfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)

Go isn’t really a C++ replacement. I‘m not sure if that solves this particular issue, Rust is provably free of data races (excluding unsafe).

is it possible to have arbitrary code execution in Go? I'm just curious.

Go has a few escape hatches like the unsafe package, but outside from that, I'm pretty sure arbexec isn't achievable in Go. The compiler inserts bounds check to prevent overflows, UAF isn't really achievable thanks to the GC, etc...

You can have UAF in Go due to slicing in the presence of concurrency: the implementation doesn't use multi-word atomics to update fat pointers like slices and interfaces. That said, it's not easy to do so.

What do you mean by memory unsafety? A stale read would be bad, but wouldn't lead to arbitrary code execution.

A 'stale' read of atomic data may be fine (it wouldn't really be "unsynchronized" in that sense), but as soon as you're dealing with stuff that's not completely atomic in-hardware and need actual synchronization, there's a potential of breaking expected invariants and creating further unsafety as a consequence of that.

I agree a stale read is bad. And I am surprised that the Go designers have repeated many past mistakes. It is possible to design a concurrent high-level language that does not have such issues, despite the hardware. For example, if all communication is done via channels, then synchronisation can be automatically performed during channel read/write. For shared mutable state, Haskell's software transactional memory and Erlang's Mnesia are both excellent examples of safely dealing with it.

The issue wrt. Go is not with communication via channels in and of itself, but rather with using channels to share pointers to in-memory data. This is idiomatic in Go, people do it all the time even though it's what introduces unsafety.

Yes, but my point is that it's a flaw in the language to allow this. Not all high-level languages share Go's problems. However, even Go would be a huge safety improvement over C++.

Go is actually one of the best in terms of design. Not every language has to be so complex. Go is easy to use and that's the point. Concurrency in it is best in class in many regards and that's what allowed the language to pretty much became THE language for backend, infrastructure and other web related things.

Rust is in completely different spectrum and doesn't compete with Go. It's much more complex, harder to write and read. That's the cost of safety. For kernel or browser engine - that's the compromise people are willing to take. For other applications - better use something else.

> Go is actually one of the best in terms of design.

I respectfully disagree. Go's primary goal was to be (superficially) easy to use and familiar. Because of this, it fails to tackle the big issue with doing concurrency in most prior mainstream languages. Go has mutable state deeply baked into the language and makes it difficult to work with immutable data. Go is not necessarily easy to use if ones goal is to build correct concurrent software.

Go's call-by-value semantics give you similar benefits. Just different tradeoffs (because there are downsides to immutable data structures).

My understanding of Go's design aesthetic is that it prefers to be explicit about things that could impact performance, which is probably why it prefers simple data structures with explicit synchronization.

You don't need to go that far. Go could have been memory-safe if slices were one word instead of three (like Java's arrays), and interfaces were one word instead of two (like Java's interfaces).

No they can't. UaF is impossible in memory safe languages like Go. Concurrency doesn't matter here. Only thing you would get is logical errors resulting in crashes or weird behavior.

Javascript, that the exploit uses, is a memory safe language too, at lest in theory...

None of the languages around, that are in major production use, are really completely memory safe in practise. There is always a runtime lurking under it, most times a libc (not in Go tho, IIRC) and assortment of various libraries written in memory unsafe languages and always a kernel.

While it's probably harder to exploit Go, as, as far as I know, most of the Go runtime is written in Go, it's not impossible, just a lot less likely.

Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++.

The problem with protecting a C++ codebase like a JS renderer is that the attacker has HUGE amounts of control. They can literally already execute arbitrary code in the renderer, making information leaks and other techniques much easier. ASLR was never intended to protect against an attacker with such a level of control.

> Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++.

Yes, that way my point. There is a runtime and/or VM and/or stdlib under these "memory safe" languages and these things are never fully written in memory safe languages themselves, at least as far as the current state of affairs goes. And even then, they run on insecure hardware (rowhammer and spectre anybody?).

Would using a language with better memory safety and other guarantees like Rust be better to write these things? Most certainly, as the attack surface becomes smaller and e.g. Rust would prevent a lot of programming mistakes in the first place. Would that be a complete silver bullet, tho? Nope.

So I agree with you that using a language with C++ isn't exactly "optimal" to implement these runtimes that are meant to run untrusted code. I just didn't like that the OP declared "memory safe languages like Go" to be a silver bullet.

>ASLR was never intended to protect against an attacker with such a level of control.

ASLR is not a protection. It's an additional roadblock put in place to make things harder for attackers once shit already hit the fan.

> There is a runtime and/or VM and/or stdlib under these "memory safe" languages and these things are never fully written in memory safe languages themselves, at least as far as the current state of affairs goes.

The ideal solution is to go beyond safe languages, and use formally verified compilers and interpreters.

'CompCert', for instance, is a formally verified C compiler [0]. (Strictly, it's a compiler for a very-nearly-complete subset of standard C.) (As an aside, I Googled for a formally verified Ada compiler, but I couldn't see any sign of one. I find that surprising.)

No reason the same couldn't be done for Rust, and/or its standard library. Would be a lot of work, of course, but it would close the door on some of the bugs you have in mind.

It wouldn't save you from operating-system bugs, but formally verified operating systems are a possibility too. [1]

> And even then, they run on insecure hardware (rowhammer and spectre anybody?).

True, but I think it's safe to say that insecure hardware isn't usually near the top of our practical security concerns. I imagine one can greatly reduce the risk of such vulnerabilities if high-performance isn't required, and AMD/Intel aren't the only options.

[0] http://compcert.inria.fr/compcert-C.html

[1] https://sel4.systems/About/seL4/

Oh, I see. I misunderstood your point.

> Would that be a complete silver bullet, tho? Nope.

I don't think anyone would disagree!

> So I agree with you that using a language with C++ isn't exactly "optimal"

Yeah, I think the distinction here is that I don't consider it "suboptimal" I consider it to be an absolute disaster. I would call rust "suboptimal" in that the language contains some soundness holes and the stdlib contains unsafe - issues, but practically still a massive improvement.

Go depends on libc on certain platforms, such as macOS.

My bullshit detector is at 3.6

Go has a garbage collector (i.e memory safety) & race detection tooling built in. https://golang.org/doc/articles/race_detector.html

Even if a race condition bug does sneak in, it won't be as catastrophic as C/C++.

Writing concurrent code is hard in any language. There's no magic bullet & Go or Rust are not immune to concurrency bugs. If anything, tools like the race detector should always come built in and every dev working on concurrent code should use one.

GC does not provide memory safety at a system level, it has the same issues as C++ in poorly programmed code once compiled. Also C++ has "memory safety" idioms similar to garbage collection through reference counting and RAII.

Google has a C++ race detector based on the Go one and it did not detect this issue (or was ignored).

Neither of those things you listed reduce the severity of the bug, and both are available in well written C++ code as google tends to do.

What do you mean? If you don't use unsafe package you can't have the same problem as C/C++ so it is memory safe. The bug in Chrome can't happen in Go without unsafe usage.

That is categorically not true.

Go compiles down to machine code, it has a stack and heap, it has structures on that stack and heap, and it has data races; those are all of the required components for a use after free. You can have data races compiled by the stock go compiler without the use of unsafe (also, why have race detector tooling if this is false?). It would probably be easier to exploit than here even because one wouldn't even need to bother with the ASLR pointer exfiltration they had to do here.

It may be harder to write exploitable code, but memory safety does not guarantee runtime memory safety. Especially in the face of concurrency.

The race condition exploits you're thinking of are not trivial and need specific code to pull off, unlikely to be a mistake like in C/C++. You just don't find them in normal Go programs.

Source (scroll down to the conclusion section): https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Having race data in your Go code doesn't mean it will be exploitable like C or C++. Same reason with Java / C# when you don't use native code.

Security bugs are unavoidable, Rust/Java or not. This calls for architectural defense in depth.

A lot of the exploits would be rendered harmless by employing well established technique of splitting one huge monolithic app into processes with limited capabilities and communicating via simple and narrow channels. Qmail[1] is a good example of such architecture. The architectural support is already present in common OSes.

--

https://en.wikipedia.org/wiki/Qmail

We should start by retiring C.

It doesn't matter if userspace is fully safe, when the basement looks like a Swiss cheese of security.

Maybe. I'm happy to run any formally verified C as my basement, for example the seL4 kernel, or for C to be used as an intermediate language. Especially as there should be less code at the bottom of the stack. But C++ seems worse, it's a far more complex language, designed and built to try and scale C to building applications. This creates a far larger attack surface.

Web browsers are unfortunately a case where even memory safe-ish languages are really an incomplete solution. Writing a JavaScript JIT in Rust won't prevent optimizer bugs.

While this is true, a lot of exploitable bugs attributed to the JS engines are actually in implementations of built-in methods (String.split, Array.join, etc.). These can benefit from memory-safe languages.

Occasionally you do just end up with straight-up exploitable optimizer bugs, though. The literature has some powerful techniques to let us get rid of those too over time, but it's not as simple as rewrite-it-in-Rust. One thing that might help is simple layering: if the JIT could compile to something like wasm as an intermediate target, then you would have an extra layer of defense against optimizer bugs. This is something that's been talked about, but I don't know if anyone has seriously looked into how practical it is.

It would add significant limits on what an optimizer bug would allow an attacker to do, though.

> Not even Google can write safe C++.

Technically it was a samsung engineer that introduced the vuln.

Those interested can check out a (nascent) "borrow checker"[1] for enforcement of C++'s memory and data race safe subset.

[1] https://github.com/duneroadrunner/scpptool

Funnily enough, looks like the vulnerability was introduced by a (korean?) samsung engineer.

fix: https://chromium-review.googlesource.com/c/chromium/src/+/18...

git blame: https://chromium.googlesource.com/chromium/src.git/+/e1fa6d4...

What a coincidence! =)

Indeed, the first google search gives his Linkedin in the first position

Operation WizardOpium, Lazarus attacks, DarkHotel, ... The executive summary reads like something out of a Charles Stross novel.

okay, I busted out loud at this one :)

This is why I started disabling js by default using ublock origin. I whitelist the websites that I'm interested in but at least I avoid a lots of exploits that requires js. This is in case if I'm unlucky and I land in one of those websites with malicious js. I discovered duckduckgo doesn't block websites as eagerly as Google and landed in a few tricky places.

If you want Google Search without Google, there's Startpage. It acts as a proxy between you and Google, protecting your privacy. I've been using it exclusively for maybe two years now. I am a bit upset at not supporting the more involved privacy-friendly projects, like DuckDuckGo or others (there are a quite a few); but, Startpage gives me the right mix of privacy, efficiency and social awareness at the moment.

Startpage was recently acquired by an ad company.

https://www.reddit.com/r/privacy/comments/di5rn3/startpage_i...

Wow. Thanks for the heads up.

I wonder if this exploit would be possible if Chrome was packaged using the UWP Desktop Bridge on Windows 10. I doubt the sandbox prevents UAF, but surely it would have prevented executing an EXE file.

I wonder the same thing with Linux contained executables, such as snap.

(not sure if chrome is available as an official snap)

It's my understanding that this particular exploit only targeted Windows, but the underlying UAF vulnerability affected all Chrome variants.

Desktop Bridge applications aren't sandboxed.

Ah so it seems. The webpage for Desktop Bridge says that it features "no malware injection", so I took that to mean it was sandboxed.

The attack code wasn't in an advert, suggesting the Korean news organisation had either previously been attacked, or had an insider plant this code.

This attack was done by North Koreans. The site is a North Korean propaganda advertising site, which is visited a lot by South Korean researchers.

That would explain the strange/weak infrastructure and the economic targets in APAC.

Is there anyway to test this on other chrome based browsers?

For example current version of Iridium is 2019.04.73.0(based on Chromium 73.0.3683.103), it doesn't get updated that often but a useful and stable browser.

Anyway to mitigate this exploit via any setting or extension?

I'll also ask is Chromium affected? And does that mean Chrome-based browsers on Android are affected too?

Attacking a Korean news website hey? I wonder who might want to do that...

Just some guy named Kenneth Osborne probably.

How can I know if I was infected and what can I do about it?

You should follow the same procedure as you do for any other, disclosed or undisclosed, infections and vulnerabilities.

Please let us know what your procedure is?

It’s checking for chrome versions below the current, 78, so update to that. You also have to be on Windows. On windows, make sure you have your antivirus setup to block random executables from download and execution. I’d also block those hosts at the firewall and dns. It gets more complicated from there if you’re infected. But you probably aren’t.

Edit-just realized you actually asked for how to tell if you were infected. Check the windows task scheduler for unknown tasks. It installs items there for persistence. Edit-search your history and hard drive for “behindcorona” domains. That’s where it loads things from. There are more specifics in the page.

Do nothing because I am not important enough to be a target of zero days

That analysis must have taken quite a while. Wasn't there any way to notify people earlier

The analysis was posted when the fix was deployed.

7th habit of Highly Effective People being to continuously Be Proactive

http://franklincoveysouthasia.com/TrainingConsulting/Trainin...

CVE no. was created in July. I wonder whether the fix took that long.

The CVE number was reserved in July[1]. That doesn't mean the vulnerability was found in July. The vulnerability was reported to Google October 29[2], so between report to fix roll out was only ~2 days. Although the bug tracker entry is hidden[3], you can deduce the time the entry was created by iterating over bug IDs, which indicates it was filed between 8:56 AM PDT[4] and 9:11 AM PDT[5].

The fix was sent for review Oct 29 4:29 PM PDT and submitted at 5:47 PM[6]. It was cherrypicked Oct 30 at 9:51 AM[7].

>Date Entry Created

> 20190718

> Disclaimer: The entry creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-13720

[2] https://chromereleases.googleblog.com/2019/10/stable-channel...

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=101922...

[4] https://bugs.chromium.org/p/chromium/issues/detail?id=101922...

[5] https://bugs.chromium.org/p/chromium/issues/detail?id=101922...

[6] https://chromium-review.googlesource.com/c/chromium/src/+/18...

[7] https://chromium.googlesource.com/chromium/src/+/f1b501721e5...

CVEs are typically reserved in blocks by big organizations.

Good eye and yes

Tragedy of our generation is that people who are so smart and determined to find and exploit these vulnerabilities, can't find better uses for their talents.

Or, maybe downloading arbitrary code from the internet without even a same-origin check, and being able to dynamically construct executable JavaScript from downloaded binary data masked as image and then have a whole generation of developers depend on this model wasn't so good an idea after all.

It enables SaaS and makes economic sense and sadly the latter is the only thing that matters when it comes to mass human behaviour.

Makes economic sense for cloud providers that is. For users, developers, content creators, and all others, not so much.

eval() has no economic purpose. It hasn't been removed by browsers purely because that would break backward compatibility.

Non-same origin Javascript does not have economic purpose either. I believe, that it will be completely eradicated from browsers within this century (if not in couple of decades).

Well the smartest talents of the previous generations built and exploded hundreds of nuclear weapons including a couple on innocent civilians, created ICBMs that can destroy civilization in a few minutes and created situations that brought the world to a brink several times, drove a massive population explosion anda fossil fuel consumption binge that may yet destroy civilization.

So I definitely think the smartest of more recent generations who are employing their skills in these software hacks and ad tracking are perhaps saintly in comparison :-)

It's not limited to "our generation", these lyrics are from 1966: https://www.azlyrics.com/lyrics/frankzappa/hungryfreaksdaddy...

Or maybe society isn't providing them an accessible application for their talents.

One good application that comes to mind in this case would be the Google Chrome bug bounty program.

The writer of this exploit was almost certainly paid more than the bug bounty reward.

Yeah, that’s a hard thing. Because the exploit is almost certainly worth more to the buyer than having it fixed is worth to Google.

> having it fixed is worth to Google

For now, I hope. Google can and should pay equivalent amounts.

Sure. I'm not saying that the moral way is just as profitable as the alternative; only that it exists.

Agreed, exploits on the deep Web pay 10x what the big bounty programs do, the mismatch is laughable

Don't improve the product, just find dumber customers!

Don’t lose weight, just buy bigger trousers!

Don’t take personal responsibility, just blame society!

Of course it's both.

Personal responsibility is important. And even if you're bored, there are things to do other than hacking.

But working mind-numbing jobs , way below one's skills and talents happens to such a large share of people.

Maybe it's a sign to a problem with society ?

Sadly, i had a big argue with my team and they kept pressing me into doing exactly the first thing. "Success depends on optimizing the sales and optimization is done by money/brains metric". Something i'm not really ready to accept (yet).

In this day and age, it could also be well paid nation state hackers. It is well understood that places like the NSA actively seek out zero day exploits and use them to perform whatever operations they need to do. They don't report them to software devs that can patch them.

His statement remains true.

> can't find better uses for their talents.

Why would they. People who break DRMs for fun and profit look with disdain at their whitehat counterparts.

Same with ad fraud. People in that particular business take pride at being able to fool boatload of best and brightest computer scientists who work at bot detection

As for people in good old browser exploit scene, I think they have good time laughing at vain efforts, and ineptness of their counterparts too

I think people are wrong thinking of it as a money thing

As I understand these RCEs (in general; perhaps not this particular one), a frequent root cause seems to be saving instruction pointer on the stack adjacent to untrustworthy data which may have propagated down the call chain. Are there no initiatives being attempted to change this convention? Like not save the IP on the stack? Perhaps at the CPU architecture level or at the compiler level?

Wikipedia ROP article has a whole section on defense techniques

https://en.m.wikipedia.org/wiki/Return-oriented_programming

Note that this was a heap attack (free after use)

Control flow integrity is the group of techniques meant to deal with this problem. There are settings for Microsoft’s cpp compiler to enable them but the best way to accomplish this is with a hardware shadow stack. Intel cet does this but I’m not sure when the hardware will be available.

There are already many modern mitigations present to defeat the kind of stack overflow control of the instruction pointer that you're imagining -- stack canaries, DEP, ASLR, NX, and others.

Simply gaining control of the instruction pointer through a stack overflow as you describe stopped working a decade or so ago due to these mitigations.

DEP and NX are essentially the same thing, FYI.

There is SafeStack https://clang.llvm.org/docs/SafeStack.html which splits stack in to two parts.

This is completely unrelated to this class of issue. You’re thinking of stack-based buffer overlows. This is all about heap manipulation, and doesn’t involve an overflow. Not in that sense anyway.

this only affects windows users, right?

Well, Chrome is indeed the new Internet Explorer. A new favorite target for threat actors.

After one 0-day?

This wasn't literally the first one I think?

Far from it. Here's an older one this year: https://chromereleases.googleblog.com/2019/03/stable-channel...

"Far from it", as you link to literally the only other case.

They had plenty, its good marketing they do.

There have been two ITW attacks on Chrome ever.