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

81–90 of 150 posts

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

#81

Post by schleyreuth »

dclusin wrote: post #32
Sunspark wrote: post #21

Earlier quoted context omitted.

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…

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.

Also be aware of the sideband interface[1] available to the IPMI by checking the block diagram in your motherboard's manual. For instance, here's AsrockRack's X470D4U diagram[2] showing the IPMI can be accessed directly through its dedicated NIC and also sideband through one of the main NICs.

[1] https://en.wikipedia.org/wiki/NC-SI [2] https://i.ibb.co/dL1tNCq/image.png

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

#82

Post by charcircuit »

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

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.

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

#83

Post by stjohnswarts »

relaunched wrote: post #78
_Nat_ wrote: post #48

Earlier quoted context omitted.

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…

I've been in the security field a while, what exactly do you mean by provably secure?

What he wants is basically impossible for software projects as big as v8 or chrome, but I guess one can dream :)

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

#84

Post by OscarDC »

creata wrote: post #50
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…

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

> just watching videos [...] (where the JavaScript takes a back seat)

If you're talking about media websites like YouTube, Netflix, Amazon Prime Video, Twitch and so on or even just videos on sites like Facebook, video streaming actually needs a lot of JavaScript behind the hood. Some of it even being already performance-sensitive today.

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

#86

Post by stjohnswarts »

creata wrote: post #59
TT-392 wrote: post #55

Anyone know if qutebrowser is affected?

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

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

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

#87

Post by stjohnswarts »

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.

That does close the window of attack to a much smaller area so yeah that improves your security statistically.

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

#88

Post by nieve »

the_common_man wrote: post #65
fn-mote wrote: post #42

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.

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

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

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

#89

Post by fulafel »

meibo wrote: post #43
_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…

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

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

#90

Post by creata »

stjohnswarts wrote: post #86
creata wrote: post #59

Earlier quoted context omitted.

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

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

Thanks, I didn't think about that.
Post reply on HN