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?
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.
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.
> 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.
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.
>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.
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?
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?
> 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.
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.
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.
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 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.
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.
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.
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:
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
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.
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.
> 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.
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 ...)
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.
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.
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.
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.
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.
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?
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.
suigetsusake|3 years ago
[0] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
ainar-g|3 years ago
https://github.com/v8/v8/commit/0981e91a4f8692af337e2588562a...
https://github.com/v8/v8/commit/a2cae2180a7a6d64ccdede44d730...
Although there could be others.
menomatter|3 years ago
emerged|3 years ago
kerneloops|3 years ago
[deleted]
tommiegannert|3 years ago
https://chromereleases.googleblog.com/2022/03/stable-channel...
rikroots|3 years ago
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
techolic|3 years ago
metadat|3 years ago
On my device the version is stuck at: 99.0.4844.73
_Nat_|3 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.?
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.
meibo|3 years ago
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.
gruez|3 years ago
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...
azornathogron|3 years ago
kerng|3 years ago
Update: found the original blog from Microsoft, they call it Super Duper Secure Mode: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
Ourgon|3 years ago
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.
flotzam|3 years ago
charcircuit|3 years ago
azornathogron|3 years ago
Of course, it won't help you since it's not built into a web browser.
svenfaw|3 years ago
So if you're OK with the limited compatibility, it might be worth considering.
lcall|3 years ago
paxys|3 years ago
mdb31|3 years ago
gruez|3 years ago
cors-fls|3 years ago
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...
lcall|3 years ago
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.
newman555|3 years ago
fn-mote|3 years ago
For all of the (deserved) hate snap gets, there are some shining up sides.
the_common_man|3 years ago
nathants|3 years ago
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|3 years ago
> 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.
t3odump|3 years ago
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 ...)
janci|3 years ago
buro9|3 years ago
dknecht|3 years ago
stjohnswarts|3 years ago
eezurr|3 years ago
djokkataja|3 years ago
bArray|3 years ago
ruuda|3 years ago
dijit|3 years ago
amelius|3 years ago
neoneye2|3 years ago
scambier|3 years ago
sysOpOpPERAND|3 years ago
should i switch browsers all together?
eternityforest|3 years ago
hulitu|3 years ago
whatev1942|3 years ago
paulpauper|3 years ago
badrabbit|3 years ago
ineedasername|3 years ago
throwaway684936|3 years ago
baby|3 years ago
TT-392|3 years ago
The-Compiler|3 years ago
creata|3 years ago
dijit|3 years ago
johndfsgdgdfg|3 years ago
[deleted]
ptk|3 years ago
aceBacker|3 years ago
hungryforcodes|3 years ago
baq|3 years ago
draw_down|3 years ago
[deleted]
octoberfranklin|3 years ago
When there is only one other complete implementation of these "standards" (with miniscule market share), it's time to panic.
dclusin|3 years ago
Is there anyway we could benefit from starting again and building a secure os from first principles? Isn’t this one of Fuscias goals?
bawolff|3 years ago
kerng|3 years ago