Looks like 99.0.4844.84 is the release we want.
https://chromereleases.googleblog.com/2022/03/stable-channel...
Chrome 0day is being exploited now for CVE-2022-1096; update immediately
11–20 of 150 posts
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#12When the web "standards" are so insanely complicated that even Google can't implement them securely, it's time to admit that we have a problem. When there is only one other complete implementation of these "standards" (with miniscule market share), it's time to panic.
Dont think this has todo with web standards, its probably JIT related. Google should just turn that off, majority of 0 days seem to be because of that.
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#13Type confusion in V8... May well impact Cloudflare workers too.
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#14Is Electron at risk too?
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#15When the web "standards" are so insanely complicated that even Google can't implement them securely, it's time to admit that we have a problem. When there is only one other complete implementation of these "standards" (with miniscule market share), it's time to panic.
It feels to me like the entire os security model is broken and leaving security up to applications even well resourced ones like chrome is a fools errand.
Is there anyway we could benefit from starting again and building a secure os from first principles? Isn’t this one of Fuscias goals?
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#16> Not much is known, at least publicly, at this stage about CVE-2022-1096 other than it is a "Type Confusion in V8." This refers to the JavaScript engine employed by Chrome. Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.? I feel like, in most cases, I could make due with JavaScript being 10x or even 1…
> I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so forth -- if it meant being able to enable it without needing to worry about new zero-days.
Not on the "modern web" you wouldn't, even the current speedy versions of V8 and ${whatever}monkey now used by Firefox the thing often is brought to a crawl by the deluge of Javascript. Imagine your current browser, only 100 times slower and 10 times more memory-hungry.
Nope, the solution lies in getting rid of most of the Javascript on most pages. uBlock and uMatrix can help a bit but the real solution lies with web developers. If and when that goal is achieved 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.
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#17> Not much is known, at least publicly, at this stage about CVE-2022-1096 other than it is a "Type Confusion in V8." This refers to the JavaScript engine employed by Chrome. Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.? I feel like, in most cases, I could make due with JavaScript being 10x or even 1…
> I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so forth -- if it meant being able to enable it without needing to worry about new zero-days. Not on the "modern web" you wouldn't, even the current speedy versions of V8 and ${whatever}monkey now used by Firefox the thing often is brought to a crawl by the deluge of…
> 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.
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#18Is Electron at risk too?
If your Electron app executes third party, remote code. But if it does, you should definitely not use it.
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#19> Not much is known, at least publicly, at this stage about CVE-2022-1096 other than it is a "Type Confusion in V8." This refers to the JavaScript engine employed by Chrome. Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.? I feel like, in most cases, I could make due with JavaScript being 10x or even 1…
>Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.?
You can disable JIT in firefox[1], which makes it fall back to an interpreter. That should theoretically make it safer as there are less optimizations going on and less generated code being directly executed by the CPU.
[1] https://github.com/arkenfox/user.js/blob/b4225baaf2f8d15f856...
Re: Chrome 0day is being exploited now for CVE-2022-1096; update immediately
#20Is there a site/service/mailing list that provides notifications for critical/RCE/in-the-wild exploit patches? Keeping every piece of software you run up-to-date takes a lot of work, and something like that would help with knowing what to prioritize.