Chrome 0day is being exploited now for CVE-2022-1096; update immediately (opens in new tab)

I have 99.0.4844.88, updated yesterday. The release notes for Android don't mention the CVE. https://chromereleases.googleblog.com/2022/03/stable-channel...

> V8 is hardened, battle-tested and fuzzed/verified by the best engineers

It's built on unsound foundations that causes an endless stream of this kind of bugs. They make compromises regarding security engineering and then do indeed put a fair amount of engineering resources to mitigate the resulting security problems.

This can be said to be good or bad engineering depending on your viewpoint, the alternatives might for example have performance tradeoffs and it can be valid engineering to make tradeoffs that favour other things at expense of security. But also we certainly do know practical and proven ways to eliminate this class of memory safety bugs in JS implementations, so it's definitely an engineering choice.

I'd prefer a [provably secure](https://en.wikipedia.org/wiki/Provable_security ) JavaScript-engine as a default. Or, if provable-security would be a bit much for a near-term project, something more heavily based in a simple engine-design, without trying to optimize stuff and perhaps including seemingly-redundant run-time checks.

Ya know, stuff like type-checking arguments, using stronger restrictions on async-calls to avoid potential race-conditions, more parameter-validation, relying on automatic-memory-management to avoid bugs, always bound-checking on array-accesses, always overflow-checking math, and so forth. In general, code that's designed to be simple and plainly correct, resisting the temptation to optimize.

Don't get me wrong, I appreciate that a lot of security-folks do good work trying to help identify-and-patch vulnerabilities in V8/etc.. And I appreciate that that enables a balance between performance and security that might be right for some applications. However, there're a lot of cases where I'd prefer a heavier focus on security.

> JavaScript engines with any kind of usable performance are inherently complex

Depends on what you're using it for, surely? If you're just watching videos or scrolling through the news (where the JavaScript takes a back seat) then wouldn't any implementation be fast enough?

You can disable jit in Chromium browsers via flag as well. Chromium Edge has this exposed in the UI as "Super Duper Secure Mode".

I'm not sure if there is a way to do this on Safari.

you can also install Fennec on Android, which has much more privacy extensions, and a better JavaScript engine (a Firefox fork).

on the PC Firefox is good enough.

Yup, that's the current strategy.

However, I'd prefer to have a secure JavaScript-engine that could be kept on by default, then enable a fast JavaScript-engine on a per-site basis.

For example, I have an exception on here for HackerNews to use JavaScript. But the JavaScript HackerNews uses is trivial; a naive JavaScript engine that's 1000x slower and uses 100x the RAM probably wouldn't even make an observable difference, would it? Except if it's secure, then I could've just had JavaScript on by default (without needing to add an exception), and then I wouldn't have to worry about stuff like if HackerNews gets compromised one day.

A lot of sites seem to do really little things with JavaScript, but break if it's disabled -- some blog sites won't even load posts without JavaScript enabled. It'd be nice to just have a secure browser to view such things with.

Try running the modern web without a supported GPU (eg through VNC on a VM with a vesa video card).

Even trivial sites will knock over the fastest Xeon available. I can't imagine how much worse it would be if you also disabled the JS JIT.

> it would be possible to browse the web using a slow-but-'safe' browser. Some pages (e.g. SPAs) really depend on all that Javascript and as such won't be useable withour 'modern' JS engines but there is no reason for e.g. your bank or payment processor's pages to depend on near-native speed Javascript engines.

I don't plan on my bank trying to 0day my browser. If anything, I trust them not to do anything malicious more than the sites that actually need to go fast.

I've been waiting for the arguments against Flash and Java applets (constant vulnerabilities + sites clogged with bad code) to finally become the argument against Javascript. Still waiting. The only reason it hasn't seems to me the massive investment by Google in speeding up the engine to the point where something even slower and more full of crud can seem relatively snappy on a mobile device.

whenever someone says "the solution is" and then says something that depends on a bunch of individual actors acting of their own accord rather than something systemic, it's hard to take them seriously. in a hypothetical dream world that might be a solution.

>it's still maintained security-wise (and will be forever, as per MS),

Source? According to microsoft:

>Please note that the Internet Explorer (IE) 11 desktop application will end support for certain operating systems starting June 15, 2022

>Customers are encouraged to move to Microsoft Edge with IE mode. IE mode enables backward compatibility and will be supported through at least 2029. Additionally, Microsoft will provide notice one year prior to retiring IE mode.

Your best bet right now for IE 11 is an installation of windows server 2022, which contains IE 11 and will be supported till Oct 14, 2031. Still, it's unknown whether IE 11 would be supported by then.

It depends on what "Javascript engine" means, and what sort of javascript you want to execute.

If you want something that can run ES5 code, this might be your ticket. But if you want something that can run "modern javascript" (where the meaning of "modern" changes over time), then IE11/Trident won't help. It doesn't even support ES6, which came out in 2015. Modern websites often depend on javascript language features newer than that. Npm packages are the same.

[1] https://kangax.github.io/compat-table/es6/

i think the problem with IE11 is going to be the rendering moreso than the javascript engine. it doesn't support css variables and only a custom version of the grid syntax, so sites are only going to get more broken

I just love MS. A company so focused on security and caring about its customers. I always encourage people to use Edge. We need to stop spyware companies like Google.

According to this analysis from Mozilla, over half of "in the wild" exploited vulnerabilities in chrome use bugs in the javascript JIT compiler.

https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO...

https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO...

(these links were found here https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...)

So it does appear that there is a fairly heavy connection between the two things.

I am not an expert in JITs or JIT related security issues, but from my understanding, since JITs get to bypass the normal W^X memory restrictions, it makes it a really nice target for exploits and RCE.

For a simple example, [integer-overflow attacks](https://www.sciencedirect.com/topics/computer-science/intege... ) could be trivially prevented by always bounds-checking integers.

For another simple example, [buffer-overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation ) could be trivially prevented through the same sorts of checks.

A popular website for programmers, [StackOverflow](https://stackoverflow.com/ ), was named after this sort of thing.

Then there're memory-management errors that could be prevented through automated-memory-management (e.g., [use-after-free](https://en.wikipedia.org/wiki/Dangling_pointer#Security_hole... )), invalid-parameter exploits that could be prevented by parameter-validation, format-exploits that could be prevented by proper encoding (e.g., [SQL injection](https://en.wikipedia.org/wiki/SQL_injection )), etc..

Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either.

A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.

>[2] https://cert.europa.eu/cert/newsletter/en/latest_SecurityBul...

I took a look and my first impressions are not good.

1. like you mentioned, the signal to noise ratio is pretty bad. eg. "OpenSSL/LibreSSL Vulnerability (CERT-EU Security Advisory 2022-017)" which is a DoS exploit that consumers would likely not care about. There's also no vendor/product filter, so I get notifications about "H2 Database Console" that I don't care about.

2. It's slow/out of date. eg. "Multiple Vulnerabilities in VMware (CERT-EU Security Advisory 2022-013)" was published on February 17, 2022, but the patch was published January 15th, a month earlier.

Do we know for sure the vulnerability was only in that version?

filtering upstream is easy, just send all traffic to a linux wireguard server and run a snitch there. getting the gui prompt is a bit tricker. for maximum trust, that gui should probably be on another device than the original machine. ie a push notification to your phone.

This is a 0 day for anything that uses V8 to execute possibly-malicious JavaScript.

Node.js and Electron aren't designed to do that in the first place, so this doesn't really affect them.

>If your Electron app executes third party, remote code.

There's a high chance that it does because of embedded content/ads/iframes/in-app browsers.

because qtwebengine isn't updated nearly as often and this appear to be a recent bug not a long running one.

You have to start further back than you realize. Almost all computers nowadays ship with a second dedicated CPU and OS that you can't access or shut off. They are network self-aware and it is a backdoor. The most well known one is called the Intel Management Engine.

There is no point having better software if you can't even secure the hardware. Yes, the risk is minimal because even if the key to the ME leaks, it will never be given away or sold because it's too valuable. It is still a sense of disquiet for me that it is there in the first place. It doesn't add to the performance or security of your existing setup. It is there to make things easier for others.

But we do know that it is Javascript-related, so please correct me if I'm wrong but disabling JS for all websites except the ones you really, really trust and need should offer long-term general protection against such 0-days in most cases.