Chrome 0day is being exploited now for CVE-2022-1096; update immediately

https://www.forbes.com/sites/daveywinder/2022/03/26/google-confirms-emergency-security-update-for-32-billion-chrome-users-attacks-underway/

by gargarplex • 4 years ago

265 141 4 years ago

forbes.com

_Nat_5• 4 years ago

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

kerng2• 4 years ago

Microsoft has added some mitigtions to Edge a few months ago as defense in depth - wondering now if this is actually exploitable on Edge or if their mitigations prevent it? Any Microsoft/Edge security people on here?

Update: found the original blog from Microsoft, they call it Super Duper Secure Mode: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Ourgon2• 4 years ago

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.

bastawhiz4• 4 years ago

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.

asddubs2• 4 years ago

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.

hedora• 4 years ago

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.

noduerme• 4 years ago

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.

gruez5• 4 years ago

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

zamadatix3• 4 years ago

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.

rurban2• 4 years ago

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.

svenfaw• 4 years ago

For Windows, IE11/Trident. This may sound ridiculous, but if you think about it, it's still maintained security-wise (and will be forever, as per MS), and since its codebase has been frozen a few years ago, its attack surface can only shrink with time.

So if you're OK with the limited compatibility, it might be worth considering.

gruez5• 4 years ago

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.

asddubs2• 4 years ago

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

johndfsgdgdfg• 4 years ago

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.

josephg• 4 years ago

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/

azornathogron2• 4 years ago

If you're worried about browser vulnerabilities in the javascript engine, have you considered disabling javascript by default and enabling it per-site on just the sites that you trust?

_Nat_5• 4 years ago

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.

flotzam• 4 years ago

Maybe JIT-less V8: https://v8.dev/blog/jitless

meibo2• 4 years ago

What you're asking for will probably put you more at risk than V8 does:

1) JavaScript engines with any kind of usable performance are inherently complex

2) V8 is hardened, battle-tested and fuzzed/verified by the best engineers at Google and indepentently by third party researchers, since inception - the engine you will be using probably won't be

All of this is really a side-effect of Chrome's popularity and Google's resources, even the CVE itself. You would be relying on security by obscurity(in which obscurity = no big userbase = not a high value target). Have a look at payouts for RCE-capable V8 bugs.

_Nat_5• 4 years ago

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.

creata4• 4 years ago

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?

fulafel2• 4 years ago

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.

azornathogron2• 4 years ago

There are certainly other javascript implementations. For example, here's one I stumbled upon recently that's written in plain Go: https://github.com/dop251/goja

Of course, it won't help you since it's not built into a web browser.

paxys2• 4 years ago

You are making the assumption that an engine with fewer optimizations that runs slower will be safer by default, but I fail to see the connection between the two.

chlorion• 4 years ago

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

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

_Nat_5• 4 years ago

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.

charcircuit• 4 years ago

Don't forget that there is a sandbox. Even if there is a vulnerability with V8 you need to pair it with a vulnerability with the sandbox to exploit the system.

lcall2• 4 years ago

I like that in chrome one can turn off javascript and images by default, then re-enable it for select sites only, or leave a tab open to re-enable it temporarily only.

baq• 4 years ago

Just what the doctor ordered in the middle of a war which is also waged in the information space. Hopefully the fact that it’s in v8 will take the exploit a bit longer than usual to proliferate.

mdb31• 4 years ago

Chromium-based versions of Microsoft Edge are also vulnerable: updating to 99.0.1150.55 fixes this CVE

paulpauper• 4 years ago

this just goes to show that updates are always 2 or so steps behind. It's a near certainty that governments, top criminal organizations have a trove of exploits for all major programs, and new ones created after old ones get patched.

suigetsusake• 4 years ago

It looks like this impacts all chromium-based browsers [0] which might not be obvious (was not for me anyway)

[0] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

octoberfranklin• 4 years ago

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

bawolff2• 4 years ago

There is no indication yet that this is due to complex web standards. It could be, but we literally dont know what the bug is yet.

hdjjhhvvhga2• 4 years ago

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.

kerng2• 4 years ago

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.

dclusin3• 4 years ago

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?

Sunspark• 4 years ago

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.

tommiegannert• 4 years ago

Looks like 99.0.4844.84 is the release we want.

https://chromereleases.googleblog.com/2022/03/stable-channel...

metadat2• 4 years ago

It's definitely not yet out for Android.

On my device the version is stuck at: 99.0.4844.73

lern_too_spel• 4 years ago

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

techolic• 4 years ago

I just upgraded to this and noticed the Reading List has changed design again! They must have gone back and forth thousands of times on this so hopefully this is the final version.

rikroots• 4 years ago

Release 99.0.4844.84 has borked my JS canvas library. Currently working on a fix - it was my misunderstanding of the purpose of the CanvasAPI willReadFrequently flag that left the library open to a severe speed degradation.

In my defence the documentation implies that the willReadFrequently flag is only a hint to the browser, to take a different approach when performing getImageData() operations[1]. However setting the flag to true also impacts drawImage() functionality[2].

I tried reporting the issue as a bug last night - at the very least the issue needs to be documented - but the form for reporting issues kept collapsing on me so I gave up.

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...

[2] - minimum demo of issue - https://codepen.io/kaliedarik/pen/bGaqMVj

buro9• 4 years ago

Type confusion in V8... May well impact Cloudflare workers too.

dknecht• 4 years ago

We have already tested and global rollout started earlier today.

stjohnswarts5• 4 years ago

Yeah wondering if this also a 0 day for node.js and electron apps...

kentonv3• 4 years ago

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.

amelius• 4 years ago

Is Electron at risk too?

scambier• 4 years ago

If your Electron app executes third party, remote code. But if it does, you should definitely not use it.

gruez5• 4 years ago

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.

neoneye2• 4 years ago

Visual Studio Code is built with Electron. VSCode has lots of extensions available. Can a VSCode extension exploit this 0day?

gruez5• 4 years ago

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

cors-fls• 4 years ago

Yes ! Computer Emergency Response Teams (CERT)[1] exist in most countries and publish security advisories as newsletters or RSS. e.g. CERT-EU security advisories [2]

But there are so many softwares and exploits that the signal to noise ratio is low if you are not in charge of a big IT infra.

[1] https://en.m.wikipedia.org/wiki/Computer_emergency_response_...

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

gruez5• 4 years ago

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

newman555• 4 years ago

funny enough, was asking my self the same question yesterday after 5-minute googling didn’t get me anywhere. I see a recommendation mentioned below, but as I also saw, hard to find something where you can control signal to noise ratio

lcall2• 4 years ago

I subscribe to debian and openbsd security advisory email lists, which works for me generally to know what is going on in the space(s) I care more about:

https://lists.debian.org/debian-security-announce/ (this one covers security updates to many packages, but not as much as CVE advisories cover, windows, etc)

https://www.debian.org/security/

https://www.openbsd.org/mail.html (ctrl-f for security, but unlike the debian ones, this only covers patches to the base OS, not other packages).

But for you of course it would depend on what you run and what matters to you.

janci• 4 years ago

Is Chrome for android affected? And V8 in nodejs?

fn-mote• 4 years ago

I use snap for some applications in spite of the trouble it has caused me. I was super-happy to find out that it had upgraded me to a not-vulnerable verson of chromium before I even knew to look.

For all of the (deserved) hate snap gets, there are some shining up sides.

the_common_man• 4 years ago

I use apt and it didn't update to this vulnerable version in the first place, so there's that

nieve• 4 years ago

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

badrabbit• 4 years ago

Is there a public exploit for this? Working on detecting browser exploitation myself.

throwaway684936• 4 years ago

I believe more details are usually published after most people are given a chance to update.

ineedasername• 4 years ago

If you mean in-the-wild, then yes: https://securityboulevard.com/2022/03/google-chrome-cve-2022...

baby• 4 years ago

Let's give people a chance to update before spreading these please

ruuda• 4 years ago

Type confusion in V8 ... Fortunately I turned off javascript by default since Meltdown/Spectre.

dijit2• 4 years ago

I did the same. But the web is basically unusable for me now and devs seem unsympathetic.

TT-392• 4 years ago

Anyone know if qutebrowser is affected?

dijit2• 4 years ago

Yes

creata4• 4 years ago

Why wouldn't it be? It uses Chromium (via QtWebEngine) by default.

stjohnswarts5• 4 years ago

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

The-Compiler2• 4 years ago

See https://www.reddit.com/r/qutebrowser/comments/tpuqj5/qutebro... - it seems to be, unfortunately.

ainar-g• 4 years ago

Looks like these are the two commits, based on the issue number:

https://github.com/v8/v8/commit/0981e91a4f8692af337e2588562a...

https://github.com/v8/v8/commit/a2cae2180a7a6d64ccdede44d730...

Although there could be others.

emerged• 4 years ago

Interesting, I’ve never seen the “maybe_db” style of variable naming. Makes sense but looks weird.

menomatter• 4 years ago

From those commits, would you say this is RCE vulnerability taking advantage of memory/stack callbacks? Does this mean an attacker may exploit this vulnerability to compromise an entire system?

nathants2• 4 years ago

securing a machine that is updated regularly and runs untrusted code is not realistic, monitoring network exfil is.

an exploit that cannot communicate is likely benign and easy to detect in the attempt.

monitor all outbound network connections with a gui prompt that defaults to deny. whitelist trusted domains/ip for a better experience and a bit less security.

macos has littlesnitch[1], linux has opensnitch[2], or roll your own on libnetfilterqueue[3].

bonus points if the filtering happens upstream at a router or wireguard host so a compromised machine cannot easily disable filtering.

bonus points if the filtering is at executable level granularity instead of system level.

1. https://www.obdev.at/products/littlesnitch/index.html

2. https://github.com/evilsocket/opensnitch

3. https://github.com/nathants/tinysnitch

figglestar• 4 years ago

monitor all outbound network connections with a gui prompt that defaults to deny. whitelist trusted domains/ip for a better experience and a bit less security.
bonus points if the filtering happens upstream at a router or wireguard host so a compromised machine cannot easily disable filtering.

Is it possible to combine these two with open/tinysnitch somehow? It'd be nice to easily build a whitelist but with the way Windows works I couldn't trust any firewall that was running on Windows itself.

nathants2• 4 years ago

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.

eezurr• 4 years ago

Anyone know if this affects Vivaldi? I assume it does since it's chromium based, but there isn't an update available.

djokkataja• 4 years ago

There's an update for the desktop browser: https://vivaldi.com/blog/desktop/minor-update-five-5-1/

bArray• 4 years ago

Just added a bug for the Ubuntu Chromium dev PPA to update their packages: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+...

sysOpOpPERAND• 4 years ago

why is chrome having so many updates within the past few months? is it because of coverage? (more users?). i use chrome off and on between that and firefox depending on the site and i am surprised how often i've been reading about issues with chrome.

should i switch browsers all together?

hulitu• 4 years ago

Every browser has updates every couple of weeks (without bringing nothing new). Quality of SW development has plumeted.

eternityforest2• 4 years ago

Basically everyone seems to be getting hacked. It's like all the hackers in the world snorted something and have been hacking nonstop all month.

whatev1942• 4 years ago

What about CloudFlare ? Does this bring to question their decision to use V8 ?

t3odump• 4 years ago

I would like to analyze the issue of browser security without controversy. The mitigations that Edge puts into practice (I'm talking about "Super Duper Secure" and "Enhanced Security") can prevent the operation of exploits in the V8 engine like this 0-day?

Is this platform dependent or the mitigation in progress works well? I mean for example some feature on mac and Linux is available out of the box asACG feature.

This analysis is very interesting because I have only read analisys related to privacy and not about security and integrity. (I mean compare between Chorme, Edge, Brave, etc ...)

Chrome 0day is being exploited now for CVE-2022-1096; update immediately

Related Stories