Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: JLJ-o-matic on March 12, 2020, 09:49:40 PM
-
Using Avast Free 19.8.2393 (19.8.4257.555) ~ waiting to update program after reports here of issues with 20.1; just read about the javascript vulnerability. Prefer to continue putting off program update until this is also addressed, so question: can this vulnerability be mitigated by manually disabling "script scanning" from Protection/Core Shields/Web Shield?
-
Avast disables JavaScript engine in its antivirus following major bug
https://www.zdnet.com/article/avast-disables-javascript-engine-in-its-antivirus-following-major-bug/
Google Researchers Find Design Flaw in Avast Antivirus
https://uk.pcmag.com/security-5/125213/google-researchers-find-design-flaw-in-avast-antivirus
-
Yes. If either of those articles, which I've read, contain the answer to my question -- I missed it.
-
Dev-Info: To protect our hundreds of millions of users, we disabled the emulator. The disablement of the emulator won't affect the functionality of our AV product, which is based on multiple security layers.
-
L.S.
Google Project Zero compliancy coming into the bargain maybe? Tab bug playing into the matter?
Javascript was invented by Brendan Eich in ten days. Sorry that it cannot be made secure in 100 days ;)
Javascript exact runtime often is a good indicator as is really pentesting for sinks and sources. ;D
polonus (volunteer 3rd party cold recon website (javascript) security analyst and website error-hunter)
-
Dev-Info: To protect our hundreds of millions of users, we disabled the emulator. The disablement of the emulator won't affect the functionality of our AV product, which is based on multiple security layers.
Yes. If that sentence, which I've read, contains the answer to my question -- I missed it.
-
Dev-Info: To protect our hundreds of millions of users, we disabled the emulator. The disablement of the emulator won't affect the functionality of our AV product, which is based on multiple security layers.
Yes. If that sentence, which I've read, contains the answer to my question -- I missed it.
My reading of it is, if the emulator has been disabled (it won't be run), then so too would be the potential problem. That would give time to either fix the bug or do it another way.
You were considering disabling web shield scanning as a means of mitigation, a sledge hammer to crack a nut, the disabling of the emulator, is using a smaller hammer and allowing other functions/levels of protection to also run.
-
Dev-Info: To protect our hundreds of millions of users, we disabled the emulator. The disablement of the emulator won't affect the functionality of our AV product, which is based on multiple security layers.
Yes. If that sentence, which I've read, contains the answer to my question -- I missed it.
My reading of it is, if the emulator has been disabled (it won't be run), then so too would be the potential problem. That would give time to either fix the bug or do it another way.
You were considering disabling web shield scanning as a means of mitigation, a sledge hammer to crack a nut, the disabling of the emulator, is using a smaller hammer and allowing other functions/levels of protection to also run.
Well not necessarily -- I have no intention of "disabling web scanning" in its entirety, rather, as stated, simply disabling the "script scanning" component of it. (FWIW I use NoScript in all browsers.)
So my question remains: is the result of manually un-checking "enable script scanning" the same as the update's "disabling the emulator" - ? Or is "the emulator" a more complex function(s) which cannot be disabled by this single user setting?
-
No, these two settings are completely unrelated.
There's no settings that would disable or enable the internal emulator.
-
Dev-Info: To protect our hundreds of millions of users, we disabled the emulator. The disablement of the emulator won't affect the functionality of our AV product, which is based on multiple security layers.
Yes. If that sentence, which I've read, contains the answer to my question -- I missed it.
My reading of it is, if the emulator has been disabled (it won't be run), then so too would be the potential problem. That would give time to either fix the bug or do it another way.
You were considering disabling web shield scanning as a means of mitigation, a sledge hammer to crack a nut, the disabling of the emulator, is using a smaller hammer and allowing other functions/levels of protection to also run.
Well not necessarily -- I have no intention of "disabling web scanning" in its entirety, rather, as stated, simply disabling the "script scanning" component of it. (FWIW I use NoScript in all browsers.)
So my question remains: is the result of manually un-checking "enable script scanning" the same as the update's "disabling the emulator" - ? Or is "the emulator" a more complex function(s) which cannot be disabled by this single user setting?
Well your initial comment "can this vulnerability be mitigated by manually disabling "script scanning" from Protection/Core Shields/Web Shield?"
This was what my response was based on, which is now a moot point given Igor's post and I guess why the JavaScript emulator was disabled.
-
No, these two settings are completely unrelated.
There's no settings that would disable or enable the internal emulator.
Thank you!
-
Followup: FWIW I updated to 20.1.2397 and no apparent problems. THX