Live data from Hacker News

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

forbes.com

41–50 of 150 posts

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

#41
post #20

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.

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

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

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

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

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

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

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

#45
post #32

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.

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.

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

#46
post #22

Earlier quoted context omitted.

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.

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.

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.

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

#47
post #32

Earlier quoted context omitted.

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.

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.

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

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

#48
post #43
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…

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.

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

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

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.

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

#50
post #43
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…

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

Post reply on HN