They do run in a sandbox, and this exploit gives the attacker RCE inside the sandbox. It is not in and of itself a sandbox escape.
However if you have arbitrary code execution then you can groom the heap with malloc/new to create the layout for a heap overflow->ret2libc or something similar
The ITW exploit has some sort of sandbox escape. My money is on a kernel exploit, but there are other options - universal XSS, IPC, etc. Kernel vuln is most likely by far imo.
Chromium uses probably the single most advanced sandbox out there, at least for software that users are likely to run into.
I actually wasn't aware of that language. It was more a reference to the overblown claims Pike made in the early days of Go, where he presented it as the c++ replacement for everything Google.
Unreal C++ uses reference counting for anything that gets exposed to the Blueprints development environemnt, Blueprints themselves have automatic resource management and the new addition to the family for Fortnight levels, Verve, also uses automatic memory management.
All of which fall under the point of view of GC implementations as per CS papers and scientific research.
Go well, it could have been a Modula-3/Active Oberon language, instead it became something only a little better than Oberon-07 and Limbo, and even then it still misses features from Limbo, as its plugin package is half backed.
> 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are.
Shouldn't pages run in isolated and sandboxed processes anyway? If that exploit gets you anywhere it would be a failure of multiple layers.