On 1/10/18, Ray_Net <tbrraymond.schmit...@tbrscarlet.be> wrote: > Lee wrote on 10-01-18 05:35: >> On 1/9/18, Ray_Net <tbrraymond.schmit...@tbrscarlet.be> wrote: >>> Lee wrote on 09-01-18 13:14: >>>> On 1/8/18, Ray_Net <tbrraymond.schmit...@tbrscarlet.be> wrote: >>>>> Lee wrote on 08-01-18 23:19: >>>>>> On 1/8/18, Ray_Net <tbrraymond.schmit...@tbrscarlet.be> wrote: >>>>>>> Lee wrote on 08-01-18 01:06: >>>>>>>> On 1/7/18, Ray_Net <tbrraymond.schmit...@tbrscarlet.be> 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 <tbrraymond.schmit...@tbrscarlet.be> 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 >>> >>> My Anti-Virus had created an entry in the registry to tell microsoft >>> that he may install the patch KB4056892 >>> and the day after, windows-update runned silently installing this patch. >> >> Have you also updated your cpu microcode? >> > How to do that ? with a soldering iron ? :-)
Preferably with an update from whoever made your machine. I've got a dell, so I started here: https://www.dell.com/support/article/us/en/19/sln308587/microprocessor-side-channel-vulnerabilities--cve-2017-5715--cve-2017-5753--cve-2017-5754---impact-on-dell-products?lang=en Apply the update, do the powershell bit: PS C:\temp\2do\SpeculationControl> Get-SpeculationControlSettings Speculation control settings for CVE-2017-5715 [branch target injection] Hardware support for branch target injection mitigation is present: True Windows OS support for branch target injection mitigation is present: True Windows OS support for branch target injection mitigation is enabled: True Speculation control settings for CVE-2017-5754 [rogue data cache load] Hardware requires kernel VA shadowing: True Windows OS support for kernel VA shadow is present: True Windows OS support for kernel VA shadow is enabled: True Windows OS support for PCID performance optimization is enabled: True [not required for security] BTIHardwarePresent : True BTIWindowsSupportPresent : True BTIWindowsSupportEnabled : True BTIDisabledBySystemPolicy : False BTIDisabledByNoHardwareSupport : False KVAShadowRequired : True KVAShadowWindowsSupportPresent : True KVAShadowWindowsSupportEnabled : True KVAShadowPcidEnabled : True everything looks good .. except the POC still works :( C:\cygwin\home\Lee\t>spectre.exe Reading 40 bytes: Reading at malicious_x = 00000FE4... Success: 0x54='T' score=2 Reading at malicious_x = 00000FE5... Success: 0x68='h' score=2 Reading at malicious_x = 00000FE6... Success: 0x65='e' score=7 (second best: 0x01 score=1) Reading at malicious_x = 00000FE7... Success: 0x20=' ' score=2 <.. snip ..> Reading at malicious_x = 00001008... Success: 0x61='a' score=2 Reading at malicious_x = 00001009... Success: 0x67='g' score=2 Reading at malicious_x = 0000100A... Success: 0x65='e' score=2 Reading at malicious_x = 0000100B... Success: 0x2E='.' score=2 *sigh* latest OS update + latest BIOS update + latest CPU microcode and the proof of concept exploit still works. So we're back to noscript + requestpolicy continued as the mitigation. Lee _______________________________________________ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
