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 _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
