[HN Gopher] Chrome 0day is being exploited now for CVE-2022-1096...
___________________________________________________________________
Chrome 0day is being exploited now for CVE-2022-1096; update
immediately
Author : gargarplex
Score : 139 points
Date : 2022-03-26 17:45 UTC (5 hours ago)
(HTM) web link (www.forbes.com)
(TXT) w3m dump (www.forbes.com)
| badrabbit wrote:
| Is there a public exploit for this? Working on detecting browser
| exploitation myself.
| throwaway684936 wrote:
| I believe more details are usually published after most people
| are given a chance to update.
| ineedasername wrote:
| If you mean in-the-wild, then yes:
| https://securityboulevard.com/2022/03/google-chrome-cve-2022...
| buro9 wrote:
| Type confusion in V8... May well impact Cloudflare workers too.
| dknecht wrote:
| We have already tested and global rollout started earlier
| today.
| amelius wrote:
| Is Electron at risk too?
| scambier wrote:
| If your Electron app executes third party, remote code. But if
| it does, you should definitely not use it.
| gruez wrote:
| >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.
| ainar-g wrote:
| 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.
| nathants wrote:
| 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
| eezurr wrote:
| Anyone know if this affects Vivaldi? I assume it does since it's
| chromium based, but there isn't an update available.
| _Nat_ wrote:
| > 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.
| paxys wrote:
| 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.
| Ourgon wrote:
| > 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.
| asddubs wrote:
| 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 wrote:
| 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.
| bastawhiz wrote:
| > 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.
| tedunangst wrote:
| Even bank pages contain a lot of analytics, and any of
| those sites could be used against you.
| Ourgon wrote:
| You don't seem to understand what I wrote so I'll explain
| it:
|
| - imagine a slow-but-secure browser, 10 to 100 times as
| slow and using 10 times as much memory as stated by the
| parent poster
|
| - imagine your bank and payment processor using a minimal
| amount of Javascript on their sites to make it possible to
| use that secure-but-slow browser without incurring too big
| a performance penalty
|
| Do you now see what I mean? It is not that your financial
| institutions would zero-day you, it is that you'd use the
| secure-but-slow browser (or browser mode) to access those
| sites. Secure, because you're dealing with financial data.
| Slow because that is what the parent poster stated as the
| price he'd be willing to pay for a secure browser.
|
| You can you your insecure-but-speedy browser to watch cat
| videos where the H4CkZ0Rz can try to zero-day you to their
| hearts content because that browser does not have access to
| sensitive data. You could try to watch those cat videos
| with the secure-but-slow browser but that'd transport you
| back to the late 90's with single-digit frame rates (cat
| slide shows?).
| tedunangst wrote:
| The dangerous assumption here is that whatever sandbox
| you put the bad browser in actually contains it.
| azornathogron wrote:
| 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.
| azornathogron wrote:
| 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_ wrote:
| 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.
| gruez wrote:
| >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...
| zamadatix wrote:
| 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.
| flotzam wrote:
| Maybe JIT-less V8: https://v8.dev/blog/jitless
| kerng wrote:
| 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...
| svenfaw wrote:
| 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.
| asddubs wrote:
| 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 wrote:
| 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.
| lanstin wrote:
| My what a difference twenty years makes. the relative food
| and evil of MS and Google have totally swapped. Shows the
| cost of Google's failure to find other profitable
| businesses than ads. It is sad for the software revolution,
| with so much talent in their employees, they had so much
| potential to improve the world.
| sofixa wrote:
| Microsoft is not focused on security. The amount of
| _trivially exploitable_ extremely serious security bugs in
| Azure scream "nobody even pretends to think about security
| here".
| gruez wrote:
| >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.
| zamadatix wrote:
| A lot of confusion between various comments so far so this
| is my attempt to re-baseline:
|
| - Chakra is the JavaScript engine in I.E. 11 (and later
| forked for the old MS Edge), Trident (MSHTML) was the
| browser engine (forked into EdgeHTML for the old MS Edge).
|
| - The I.E. 11 desktop application is just that, the desktop
| application. It is not all of I.E. 11 or it's engines, the
| rest of which are still in Windows 11 even.
|
| - I.E. mode is the first party way to access the remaining
| portions of I.E. 11 via the current Chromium Edge, this is
| what allowed them to sunset the I.E. desktop application.
|
| All that said I don't particularly buy this as being
| particularly more secure. Sure, it's only getting security
| fixes but that doesn't inherently mean it is more secure or
| getting more security fixes than modern solutions. It could
| just be becoming an outdated security architecture that is
| only patched often enough to keep the minute userbase happy
| enough.
| meibo wrote:
| 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_ wrote:
| 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.
| creata wrote:
| > 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?
| johndfsgdgdfg wrote:
| aceBacker wrote:
| Heh, my corp locks down the edge updates and bundles them with
| the OS updates. Edge is going to be vulnerable to this one for
| months maybe a year longer that chrome.
| ptk wrote:
| I don't know if you're joking or not, and I say this as someone
| who uses Edge as their primary browser, but Edge does not
| improve the situation you describe. Edge is just a flavor of
| chromium at this point and absolutely gives Chrome a run for
| its money in the tracking and telemetry department.
| hungryforcodes wrote:
| Windows 10 is definitely spyware. So migrating to Edge is
| hardly a solution. Chromium on the other hand...
| ruuda wrote:
| Type confusion in V8 ... Fortunately I turned off javascript by
| default since Meltdown/Spectre.
| dijit wrote:
| I did the same. But the web is basically unusable for me now
| and devs seem unsympathetic.
| baq wrote:
| 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.
| draw_down wrote:
| gruez wrote:
| 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 wrote:
| 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...
| gruez wrote:
| >[2] https://cert.europa.eu/cert/newsletter/en/latest_Securit
| yBul...
|
| 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.
| CiPHPerCoder wrote:
| Yes, it's a firehose. I'm sure you can find a security
| vendor willing to offer a curated list somewhere.
| newman555 wrote:
| 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
| mdb31 wrote:
| Chromium-based versions of Microsoft Edge are also vulnerable:
| updating to 99.0.1150.55 fixes this CVE
| paulpauper wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kerng wrote:
| 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.
| dclusin wrote:
| 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 wrote:
| 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.
| dclusin wrote:
| The server motherboard I just bought has this as well.
| Thankfully access to it is at least isolated to a separate
| network port. I'm debating supergluing it closed or maybe
| physically disconnect the port somehow.
| jacquesm wrote:
| You may want to review that _very_ carefully, typically
| if that separate network port doesn 't have a live
| network on it that issues DHCP addresses the
| functionality will fall back to the port that _is_
| attached.
| dclusin wrote:
| Oh fun. Thank you for the tip! Any sugestions on how to
| go about this? I'm a relative newb in these matters.
| Switching from MacOS to linux daily driver
| jacquesm wrote:
| Keep an eye on ports 16992-16995, 5900, 623, 664, and
| realize that packets destined for those ports may never
| become visible to the OS so you'll have to catch them in
| transit to the board. Another place to look at is what
| DHCP leases are issued by your DHCP server, conceivably
| the management engine could request an address for
| itself.
| bawolff wrote:
| 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.
| hdjjhhvvhga wrote:
| 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.
| paxys wrote:
| There are lots of 0day exploits outside of the JavaScript
| engine. Going down this path, it would be safest to not use
| the web at all, or really just not own a computer.
| hdjjhhvvhga wrote:
| No, I think it's reductio ad absurdum; what I mean is
| reasonable means of reducing risks for people who don't
| use that much web apps and consume mostly text such as
| news etc.
| fn-mote wrote:
| 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 wrote:
| I use apt and it didn't update to this vulnerable version in
| the first place, so there's that
| TT-392 wrote:
| Anyone know if qutebrowser is affected?
| dijit wrote:
| Yes
| creata wrote:
| Why wouldn't it be? It uses Chromium (via QtWebEngine) by
| default.
| tommiegannert wrote:
| Looks like 99.0.4844.84 is the release we want.
|
| https://chromereleases.googleblog.com/2022/03/stable-channel...
| metadat wrote:
| It's definitely not yet out for Android.
|
| On my device the version is stuck at: 99.0.4844.73
| janci wrote:
| Is Chrome for android affected? And V8 in nodejs?
___________________________________________________________________
(page generated 2022-03-26 23:01 UTC)