On 1/8/18, Ray_Net <[email protected]> wrote: > Lee wrote on 08-01-18 23:19: >> On 1/8/18, Ray_Net <[email protected]> wrote: >>> Lee wrote on 08-01-18 01:06: >>>> On 1/7/18, Ray_Net <[email protected]> wrote: >>>>> Lee wrote on 07-01-18 22:44: >>>>>> summary: The vuln. mitigation is to install noscript + request policy >>>>>> continued or uMatrix + uBlock Origin or whatever other addon combo >>>>>> that allows javascript from only whitelisted sites. >>>>>> >>>>>> On 1/7/18, Ray_Net <[email protected]> wrote: >>>>>>> WaltS48 wrote on 06-01-18 18:05: >>>>>>>> On 1/6/18 2:36 AM, Ray_Net wrote: >>>>>>>>> I have read: >>>>>>>>> >>>>>>>>> "Disable Javascript until browser company comes out with patch for >>>>>>>>> vulnerable Javascript." >>>>>>>>> >>>>>>>>> So, will SM issue a patch against the Spectre exploit ? >>>>>> Mozilla needs to come up with a patch first. What they have now only >>>>>> blocks the obvious timing attack methods. >>>>>> >>>>>>>> SeaMonkey 2.49.1 is based on Firefox 52 ESR code, and Firefox 52 ESR >>>>>>>> doesn't have SharedBufferArray enabled. >>>>>>>> || >>>>>>>> ||SharedArrayBuffer| is already disabled in Firefox 52 ESR. >>>>>>>> || >>>>>>>> |REF: https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/ >>>>>>>> >>>>>>> Would it mean that we are protected ? >>>>>> No. >>>>>> >>>>>> Look at the FF advisory >>>>>> The precision of performance.now() has been reduced from 5μs to >>>>>> 20μs, and the SharedArrayBuffer feature has been disabled because it >>>>>> can be used to construct a high-resolution timer. >>>>>> >>>>>> SeaMonkey doesn't implement the SharedArrayBuffer feature but I'm >>>>>> guessing it's performance.now() function still has the 5μs resolution >>>>>> and that will take a patch to fix. >>>>>> >>>>>> But changing the performance.now() resolution is not sufficient. Take >>>>>> a >>>>>> look at >>>>>> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ >>>>>> Furthermore, other timing sources and time-fuzzing techniques are >>>>>> being worked on. >>>>>> >>>>>> Which is like saying we've locked the front door so nobody can walk >>>>>> right in anymore but the ground floor windows are still wide open. >>>>>> >>>>>> Follow the "other timing sources and time-fuzzing techniques" link to >>>>>> https://gruss.cc/files/fantastictimers.pdf >>>>>> Abstract. Research showed that microarchitectural attacks like >>>>>> cache >>>>>> attacks can be performed through websites using JavaScript. These >>>>>> timing attacks allow an adversary to spy on users secrets such as >>>>>> their keystrokes,leveraging fine-grained timers. However, the W3C and >>>>>> browser vendors responded to this significant threat by eliminating >>>>>> fine-grained timers from JavaScript. This renders previous >>>>>> high-resolution microarchitectural attacks non-applicable. >>>>>> >>>>>> >>We demonstrate the inefficacy of this mitigation<< by finding >>>>>> and >>>>>> evaluating a wide range of new sources of timing information. We >>>>>> develop measurement methods that exceed the resolution of official >>>>>> timing sources by to orders of magnitude on all major browsers, and >>>>>> even more on Tor browser. Our timing measurements do not only >>>>>> re-enable previous attacks to their full extent but also allow >>>>>> implementing new attacks. We demonstrate a new DRAM-based covert >>>>>> channel between a website and an unprivileged app in a virtual machine >>>>>> without network hardware. Our results emphasize that quick-fix >>>>>> mitigations can establish a dangerous false sense of security. >>>>>> >>>>>> >>>>>> In short, performance.now() and SharedBufferArray are the easy/obvious >>>>>> ways to get a high resolution timer in javascript but they're not the >>>>>> only possible methods. >>>>>> >>>>>> So... what to do? The exploit mitigation is to install noscript + >>>>>> request policy continued or uMatrix + uBlock Origin or whatever other >>>>>> addon combo that allows javascript from only whitelisted sites. >>>>>> >>>>>> Regards, >>>>>> Lee >>>>> For "Request Policy" we have for all versions: >>>>> This add-on is not compatible with your version of SeaMonkey. >>>> "Request Policy" was the original - you want "RequestPolicy Continued" >>>> which is easier to use: >>>> https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/ >>>> >>>> which links to >>>> https://addons.mozilla.org/firefox/downloads/file/747484/requestpolicy_continued-1.0.beta13.2-fx+sm.xpi >>>> >>>>> For "NoScript Security Suite" we have: >>>>> Only with FireFox. >>>> yeah.. you need to scroll down to 'version history' & click on 'see >>>> all versions' >>>> It looks like 5.1.8.3 is the last one that will work w/ SM >>>> Works with Firefox 45.0 - 56.0, SeaMonkey 2.42 - * >>>> https://addons.mozilla.org/firefox/downloads/file/806790/noscript_security_suite-5.1.8.3-fx+sm.xpi >>>> >>>> Regards >>>> Lee >>> Anyway, it's better that SM solve problems instead of a need to install >>> a myriad of extensions. >> agreed. But I like having more control over what's allowed than the >> javascript.enabled on/off switch & extensions are the only way I know >> of to get that. >> >> Regards >> Lee > > I think that Microsoft had installed yesterday an emergency patch for > adressing meltdown and spectre. > https://blog.trendmicro.com/fixing-meltdown-spectre-vulnerabilities/ > and .... > Microsoft yesterday released an emergency patch for Windows 10 to > address this prior to Patch Tuesday, which incorporates KAISER in KB4056892
I haven't forced an update yet; my last windows update was 12/28, so I'm still unprotected. https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050 This zip file contains a PowerShell module that can be used to confirm whether a system has enabled the protections needed to validate that the speculation control vulnerability. I just tried it and everything is false.. which agrees w/ my not getting any updates yet. Regards, Lee _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
