Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

forbes.com

Post reply on HN
Print view View original

101–110 of 150 posts

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

#101

Post by tessierashpool »

fulafel wrote: post #89
meibo wrote: post #43

Earlier quoted context omitted.

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…

> 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 f…

yeah, plus that "the best engineers at Google" has an element of hyperbole. this is one of those times where you can move a statement from being ridiculous to being correct just by throwing in a "some of." it's not like they assigned Jeff Dean to AI instead of Chrome because he just couldn't cut it.

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

#102

Post by gnu8 »

______-_-______ wrote: post #79
zamadatix wrote: post #39

Earlier quoted context omitted.

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.

I found this comparison of JIT vs non-JIT. https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... If you take those charts at face value, they're pretty incredible. The JIT ends up worse than the interpreter for most (real-world non-synthetic) use cases for power usage, memory usage, and startup time. Page load time is a wash. And this is after Google has poured $billions into optimizing V8.

I don't get why Microsoft is even working on this. They don't have a web browser.

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

#103

Post by TheDong »

paxys wrote: post #62
hdjjhhvvhga wrote: post #24

Earlier quoted context omitted.

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.

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.

My doctor told me I should stop smoking.

There are a lot of ways to die outside of lung cancer though. Going down this path, it would be safest to not drink alcohol, not drive a car, or really just not live life at all.

My point here is that there are some things that have outsized impacts and can be avoided in isolation. Smoking is like that for health.

Javascript, ActiveX, java web applets, flash, any other way of executing arbitrary turing-complete remote code on my local machine directly, those are all vastly more likely to lead to CVEs than HTML parsers, image parsers, and other functionalities of browsers.

It's perfectly possible to identity and eliminate larger attack surfaces without slippery-sloping yourself into not being able to take smaller risks.

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

#104

Post by bastawhiz »

Ourgon wrote: post #54
bastawhiz wrote: post #17

Earlier quoted context omitted.

> 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 m…

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…

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

I understood what you meant the first time. Again, the risk you're mitigating is one that simply doesn't exist. A slow but hardened engine protects against attacks that simply don't happen for the sites you're talking about.

The threat here is abuse of the JS engine. If you're on my bank website origin running slow JavaScript you can already steal all of my money. Hardening the JS engine for that site is pointless because any bad JS running on the page already has the literal most valuable thing I have: access to all of my money. Having a provably not-zero-day-able browser does nothing to mitigate an attack if there's bad code running on the page.

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

#105

Post by kerneloops »

ainar-g wrote: post #60

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.

No post body was provided.

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

#106

Post by bastawhiz »

tedunangst wrote: post #68
bastawhiz wrote: post #17

Earlier quoted context omitted.

> 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 m…

Even bank pages contain a lot of analytics, and any of those sites could be used against you.

All of those analytics would already have the ability to run in the bank's origin and steal my money. What threat model are you operating under where malicious code running on your bank's website is trying to do something other than steal all of your money (which they're already able to do if they're executing on the bank's origin)?

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

#107

Post by tedunangst »

bastawhiz wrote: post #106
tedunangst wrote: post #68

Earlier quoted context omitted.

Even bank pages contain a lot of analytics, and any of those sites could be used against you.

All of those analytics would already have the ability to run in the bank's origin and steal my money. What threat model are you operating under where malicious code running on your bank's website is trying to do something other than steal all of your money (which they're already able to do if they're executing on the bank's origin)?

The threat model where the analytics company is hacked. I don't know why you would trust your bank to never let that happen.

There are some APIs on the bank site you need to conduct your business, and there are also some extraneous APIs. Yeah, sure, you tell the bank it's their fault clickwatcher.js got hacked, and maybe they give you your money back, but it seems like unnecessary exposure to unnecessary hassle to leave all that crap running fully trusted.

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

#108

Post by chlorion »

paxys wrote: post #61
_Nat_ wrote: post #2

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

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.

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.

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

#109

Post by techolic »

tommiegannert wrote: post #11

Looks like 99.0.4844.84 is the release we want. https://chromereleases.googleblog.com/2022/03/stable-channel...

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.

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

#110

Post by bastawhiz »

tedunangst wrote: post #107
bastawhiz wrote: post #106

Earlier quoted context omitted.

All of those analytics would already have the ability to run in the bank's origin and steal my money. What threat model are you operating under where malicious code running on your bank's website is trying to do something other than steal all of your money (which they're already able to do if they're executing on the bank's origin)?

The threat model where the analytics company is hacked. I don't know why you would trust your bank to never let that happen. There are some APIs on the bank site you need to conduct your business, and there are also some extraneous APIs. Yeah, sure, you tell the bank it's their fault clickwatcher.js got hacked, and maybe they give you your money back, but it seems like unnecessary exposure to unnecessary hassle to le…

But having a more hardened browser literally does nothing to protect you. If your bank's website is hacked because of a third party API, the most well-hardened browser (as the commenter that I replied to describes) in the world will happily allow all of your money to be stolen. A slow-but-secure JS engine does not protect you from JS that's doing things it's allowed to do.
Post reply on HN