subject:"Spectre exploit"

Re: Spectre exploit

2018-01-14 Thread Mason83

On 12/01/2018 22:38, Mark wrote:

> Don't the OS kernel / BIOS / CPU updates just mitigate against Meltdown, 
> preventing applications (executing in ring3) from inferring content of 
> kernel memory (in ring0)?

AFAIU, the kernel work-around for Meltdown is /not/ mapping the
kernel inside an application's virtual memory space.

BIOS and CPU updates are the same. Intel makes a microcode update,
and BIOS vendors integrate that to patch the CPU at boot.

Is there a microcode update for Meltdown? I thought they were only
mitigating Spectre.

Regards.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Spectre exploit

2018-01-13 Thread Lee

On 1/12/18, mozilla-lists.mbou...@spamgourmet.com
 wrote:
> Lee wrote:
>> 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 = 0FE4... Success: 0x54='T' score=2
>> Reading at malicious_x = 0FE5... Success: 0x68='h' score=2
>> Reading at malicious_x = 0FE6... Success: 0x65='e' score=7 (second
>> best: 0x01 score=1)
>> Reading at malicious_x = 0FE7... Success: 0x20=' ' score=2
>> <.. snip ..>
>> Reading at malicious_x = 1008... Success: 0x61='a' score=2
>> Reading at malicious_x = 1009... Success: 0x67='g' score=2
>> Reading at malicious_x = 100A... Success: 0x65='e' score=2
>> Reading at malicious_x = 100B... Success: 0x2E='.' score=2
>>
>> *sigh*  latest OS update + latest BIOS update + latest CPU microcode
>> and the proof of concept exploit still works.
>
> Don't the OS kernel / BIOS / CPU updates just mitigate against Meltdown,
> preventing applications (executing in ring3) from inferring content of
> kernel memory (in ring0)?

There were also a few other items in the BIOS update for my pc that
sounded good but yes -- it seems like most of the frenzy was about
Meltdown.  Which is a big deal for cloud providers but probably
doesn't matter all that much to me.  On the other hand, the powershell
Get-SpeculationControlSettings shows I've got [dunno what] mitigation
enabled for both categories:
  Speculation control settings for CVE-2017-5715
  Speculation control settings for CVE-2017-5754
and like the song - two out of three ain't bad (altho this one's
better  https://www.youtube.com/watch?v=GMR3Hy3yrbw )

> As I understand it, I think Spectre requires workarounds in each
> application (or a fundamental change to CPU hardware to do something
> like somehow roll back the cache content along with other processor
> state when discarding speculatively executed instructions). Unless you
> patch the PoC code to mitigate Spectre, it will still demonstrate a
> successful attack.

Exactly.  And how does a user end up with attacker controlled programs
running on their computer?  I'm guessing far & away the biggest vector
is javascript running in the browser.

So people should be at least thinking about blocking javascript.  And
thinking about what kind of exposure they have with their addons (like
a password/form-fill manager that might not be safe against spectre
attacks).

Regards,
Lee
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Spectre exploit

2018-01-12 Thread mozilla-lists . mbourne


Lee wrote:

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 = 0FE4... Success: 0x54='T' score=2
Reading at malicious_x = 0FE5... Success: 0x68='h' score=2
Reading at malicious_x = 0FE6... Success: 0x65='e' score=7 (second
best: 0x01 score=1)
Reading at malicious_x = 0FE7... Success: 0x20=' ' score=2
<.. snip ..>
Reading at malicious_x = 1008... Success: 0x61='a' score=2
Reading at malicious_x = 1009... Success: 0x67='g' score=2
Reading at malicious_x = 100A... Success: 0x65='e' score=2
Reading at malicious_x = 100B... Success: 0x2E='.' score=2

*sigh*  latest OS update + latest BIOS update + latest CPU microcode
and the proof of concept exploit still works.


Don't the OS kernel / BIOS / CPU updates just mitigate against Meltdown, 
preventing applications (executing in ring3) from inferring content of 
kernel memory (in ring0)?


As I understand it, I think Spectre requires workarounds in each 
application (or a fundamental change to CPU hardware to do something 
like somehow roll back the cache content along with other processor 
state when discarding speculatively executed instructions). Unless you 
patch the PoC code to mitigate Spectre, it will still demonstrate a 
successful attack.


--
Mark.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Spectre exploit

2018-01-10 Thread Ray_Net

Lee wrote on 10-01-18 14:10:

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 ﬁne-grained timers. However, the W3C
and
browser vendors responded to this signiﬁcant threat by eliminating
ﬁne-grained timers from JavaScript. This renders previous
high-resolution microarchitectural attacks non-applicable.

>>We demonstrate the inefficacy of this mitigation<< by
ﬁnding
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-ﬁx
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

Re: Spectre exploit

2018-01-10 Thread Lee

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-fu

Re: Spectre exploit

2018-01-09 Thread Ray_Net

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.

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.

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 ﬁne-grained timers. However, the W3C and
browser vendors responded to this signiﬁcant threat by eliminating
ﬁne-grained timers from JavaScript. This renders previous
high-resolution microarchitectural attacks non-applicable.

>>We demonstrate the inefficacy of this mitigation<< by ﬁnding
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-ﬁx
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.

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-

Re: Spectre exploit

2018-01-09 Thread Lee

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 ﬁne-grained timers. However, the W3C and
>>>>>>>> browser vendors responded to this signiﬁcant threat by eliminating
>>>>>>>> ﬁne-grained timers from JavaScript. This renders previous
>

Re: Spectre exploit

2018-01-09 Thread Ray_Net

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 ﬁne-grained timers. However, the W3C and
browser vendors responded to this signiﬁcant threat by eliminating
ﬁne-grained timers from JavaScript. This renders previous
high-resolution microarchitectural attacks non-applicable.

>>We demonstrate the inefficacy of this mitigation<< by ﬁnding
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-ﬁx
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.

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

Re: Spectre exploit

2018-01-09 Thread Lee

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 ﬁne-grained timers. However, the W3C and
>>>>>> browser vendors responded to this signiﬁcant threat by eliminating
>>>>>> ﬁne-grained timers from JavaScript. This renders previous
>>>>>> high-resolution microarchitectural attacks non-applicable.
>>>>>>
>>>>>>  >>We demonstrate the inefficacy of this mitigation<< by ﬁnding
>>>>>> 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 emphasiz

Re: Spectre exploit

2018-01-08 Thread Ray_Net

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 ﬁne-grained timers. However, the W3C and
browser vendors responded to this signiﬁcant threat by eliminating
ﬁne-grained timers from JavaScript. This renders previous
high-resolution microarchitectural attacks non-applicable.

>>We demonstrate the inefficacy of this mitigation<< by ﬁnding 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-ﬁx
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.

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

Re: Spectre exploit

2018-01-08 Thread Lee

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 ﬁne-grained timers. However, the W3C and
>>>> browser vendors responded to this signiﬁcant threat by eliminating
>>>> ﬁne-grained timers from JavaScript. This renders previous
>>>> high-resolution microarchitectural attacks non-applicable.
>>>>
>>>> >>We demonstrate the inefficacy of this mitigation<< by ﬁnding 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-ﬁx
>>>> 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
&g