Re: [gentoo-user] Re: dev-libs/nss-3.29.5 security level problem?

[Mick]

On Thursday, 10 May 2018 11:31:45 BST Dale wrote:
> Mick wrote:
> > On Thursday, 10 May 2018 10:48:06 BST Mick wrote:
> >> Hi All,
> >> 
> >> I just discovered the last nss update broke things completely on mozilla
> >> apps which use nss.  Firefox now refuses to connect to any site with
> >> https.
[snip ...]

> >> Error code: NS_ERROR_NET_INADEQUATE_SECURITY
> >> 
> >> 
> >> Have you noticed the same?
> > 
> > OK, looking further into this problem, it was not an update, but a
> > downgrade which caused it.  I had previously keyworded nss-3.36 which
> > yesterday fell off the tree and portage downgraded nss to 3.29.5.  I
> > keyworded and emerge 3.37 and all works as it should again.  :-)
> 
> I ran into this as well.  There is a setting in about:config that you
> can change that makes it work.  However, if you have a fix that is
> better, your fix may be the best way.  I think it required disabling
> something in about:config, which may not be good in the long run. 
> 
> I may can dig up the link I found if you need it. 
> 
> Dale
> 
> :-)  :-) 


Thank you Dale.  I vaguely remember a post mentioning something like this.  
Since a later nss version works, I'll run with this solution for now.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Spectre-NG

[Ian Zimmerman]

On 2018-05-10 14:35, Wol's lists wrote:

> > Code may be "security-sensitive" but buggy.  Is the compiler writer
> > really responsible for guessing what the programmer meant to
> > accomplish with buggy code?
> 
> What do you mean by "buggy"?

Relying on UB, or not telling the compiler the whole truth.  You have a
point in that I should have been more specific.

> So if the compiler can't detect undefined behaviour, how the hell do
> you expect the programmer to?

Number one reason is that UB is at least in part a run-time concept.
Clearly the compiler cannot try all possible inputs to a function and
run a simulation on them.  The programmer _can_ insert guard code at the
calling site to prevent the undefined cases from happening.

A "whole program" compiler (ie. one that analyzes code across source
modules) may be able to detect the _possibility_ of UB.  But if you put
such a compiler to work on the kernel (for example), you can probably
take a short vacation while you await the result ;-)

> Oh - and please explain - what is buggy about wanting the following
> program to compile and actually *do* what the code is asking, rather
> than compiling to a no-op ... and 0x00ff is the address of your
> network adaptor? Do you want THAT to be optimised away "because it
> doesn't do anything"?

> int main () {
> int a, b, c;
> a = 2;
> b = 4;
> c = 6;
> }

> int main () {
> void *a;
> a = 0x00ff;
> *a = 6;
> }

This is actually not UB, but a different problem.  Yes, if I write it
like this, I want it eliminated.  When I want to keep it, I will use
the "volatile" keyword which is in the language precisely for this
purpose.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[gentoo-user] Re: Spectre-NG

[Martin Vaeth]

Rich Freeman  wrote:
> On Thu, May 10, 2018 at 1:34 AM Martin Vaeth  wrote:
>
>> As a simple example, assume that you have read a password file
>> into a string of your language and now access a single password.
>> No matter, how you mark the end of the password (fixed-length, \0, \n,
>> ...) speculative execution might always access the next password(s)
>> unless you prevent it globally. Whether it is exploitable depends
>> of course on other things. There is no difference to C.
>
> [...] I don't see how
> having the next password speculatively read would on its own create a
> vulnerability.

That's what I meant by "whether it is exploitable depends of course
on other things". *Most* speculative executions are probably not
exploitable, whether in C or any other language: you need a
really unfortunate setup.
However, to be on the really safe side you just have to prevent
everything which might potentially exploitable.

> You would also need some kind of indirect memory access
> based on the speculatively-accessed data

For the "classical" spectre (v2?) variant:
In the "speculative" execution you copied more data.
Exploitability depends completely on the subsequent code,
i.e. what will happen with this data (and on whether an attacker
can execute and time the whole function).

However, everybody expected (and perhaps spectre-ng will confirm that)
that there are a lot more of processor bugs involved with speculative
execution: AFAIK, there were already reports that some internal
processor bits were cleared/set depending on some results (i.e.
meltdown type bugs). So maybe just doing the right thing in another
process might reveal some information. Whether it is again possible
to fix this in the kernel is unclear yet.

> Consider:
>
> for x = 1 to 10 : y=5+3 : next x

I don't understand what you want to say here.
Of course, non-sensical code is not exploitable.
The question is whether the compiler can recognize it.
I haven't tried, but I am rather sure that the above loop disappears
in C w/ gcc -O2 due to flow analysis (the constant assertion is
pulled out and then the loop recognized as empty).

> I still tend to think that the additional context around these memory
> accesses that is available in a high-level language could be used by a
> compiler

The compiler needs to detect whether a speculative execution
might be dangerous. This is similarly hard for every Turing-complete
language; I do not see any language having a considerable advantage
for this.

Re: [gentoo-user] Re: Spectre-NG

[Rich Freeman]

On Thu, May 10, 2018 at 1:34 AM Martin Vaeth  wrote:

> As a simple example, assume that you have read a password file
> into a string of your language and now access a single password.
> No matter, how you mark the end of the password (fixed-length, \0, \n,
> ...) speculative execution might always access the next password(s)
> unless you prevent it globally. Whether it is exploitable depends
> of course on other things. There is no difference to C.


I'll just reply to this because the rest of the email is just a natural
consequence of it.

I will confess up-front I'm not an expert in Spectre, but I don't see how
having the next password speculatively read would on its own create a
vulnerability.  You would also need some kind of indirect memory access
based on the speculatively-accessed data to create a timing channel.

And of course it is entirely possible that the loop wouldn't be
sequentially reading in data in a way that could cause a bound to be
exceeded, and in this situation I don't see why protection would be
required.  Consider:

for x = 1 to 10 : y=5+3 : next x

This is obviously trivial, but I don't see how executing that loop a few
too many times would cause problems, so blocking speculation is just going
to hurt performance for no benefit.

I still tend to think that the additional context around these memory
accesses that is available in a high-level language could be used by a
compiler to determine when protection is required.

Certainly a skilled programmer might be able to do an even better job if
they were vigilant, but not all programmers are equally skilled...

-- 
Rich

Re: [gentoo-user] Re: Spectre-NG

[Wol's lists]

On 09/05/18 23:50, Ian Zimmerman wrote:

Code may be "security-sensitive" but buggy.  Is the compiler writer
really responsible for guessing what the programmer meant to accomplish
with buggy code?


What do you mean by "buggy"?


  It would of course be preferable if the compiler could
just abort with an error when it detects UB, but that turns out to be
very hard to impossible in the case of C.  That's just a built in
problem with the language.


So if the compiler can't detect undefined behaviour, how the hell do you 
expect the programmer to?


Oh - and please explain - what is buggy about wanting the following 
program to compile and actually *do* what the code is asking, rather 
than compiling to a no-op ...


int main () {
  int a, b, c;
  a = 2;
  b = 4;
  c = 6;
}

Note I did say the problem is almost invariably when hardware gets 
involved - what happens if it's


int main () {
  void *a;
  a = 0x00ff;
  *a = 6;
}

and 0x00ff is the address of your network adaptor? Do you want THAT to 
be optimised away "because it doesn't do anything"?


That's why I expect LVM/Clang is much better - because I believe Intel 
is heavily involved they provide guarantees about how the compiler will 
interact with hardware, when the C standard explicitly avoids specifying 
it (imho, the standard should require a compiler to document how it 
handles things like that ...). (Yes I believe there is some compiler 
option to make that work, but I'm pretty certain that either is or was 
undefined behaviour to start with? And if it is now standard, it's 
probably because some clever idiot optimised the "code which doesn't do 
anything" away and they had to define a way of stopping it?)


Cheers,
Wol

Re: [gentoo-user] Re: dev-libs/nss-3.29.5 security level problem?

[Dale]

Mick wrote:
> On Thursday, 10 May 2018 10:48:06 BST Mick wrote:
>> Hi All,
>>
>> I just discovered the last nss update broke things completely on mozilla
>> apps which use nss.  Firefox now refuses to connect to any site with https.
>>  Trying to load google.com brings up this error message:
>>
>> =
>> Your connection is not secure
>>
>> The website tried to negotiate an inadequate level of security.
>>
>> www.google.com uses security technology that is outdated and vulnerable to
>> attack. An attacker could easily reveal information which you thought to be
>> safe. The website administrator will need to fix the server first before you
>> can visit the site.
>>
>> Error code: NS_ERROR_NET_INADEQUATE_SECURITY
>> 
>>
>> Have you noticed the same?
>
> OK, looking further into this problem, it was not an update, but a downgrade 
> which caused it.  I had previously keyworded nss-3.36 which yesterday fell 
> off 
> the tree and portage downgraded nss to 3.29.5.  I keyworded and emerge 3.37 
> and all works as it should again.  :-)
>


I ran into this as well.  There is a setting in about:config that you
can change that makes it work.  However, if you have a fix that is
better, your fix may be the best way.  I think it required disabling
something in about:config, which may not be good in the long run. 

I may can dig up the link I found if you need it. 

Dale

:-)  :-) 

[gentoo-user] Re: dev-libs/nss-3.29.5 security level problem?

[Mick]

On Thursday, 10 May 2018 10:48:06 BST Mick wrote:
> Hi All,
> 
> I just discovered the last nss update broke things completely on mozilla
> apps which use nss.  Firefox now refuses to connect to any site with https.
>  Trying to load google.com brings up this error message:
> 
> =
> Your connection is not secure
> 
> The website tried to negotiate an inadequate level of security.
> 
> www.google.com uses security technology that is outdated and vulnerable to
> attack. An attacker could easily reveal information which you thought to be
> safe. The website administrator will need to fix the server first before you
> can visit the site.
> 
> Error code: NS_ERROR_NET_INADEQUATE_SECURITY
> 
> 
> Have you noticed the same?


OK, looking further into this problem, it was not an update, but a downgrade 
which caused it.  I had previously keyworded nss-3.36 which yesterday fell off 
the tree and portage downgraded nss to 3.29.5.  I keyworded and emerge 3.37 
and all works as it should again.  :-)

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: dev-libs/nss-3.29.5 security level problem?

[Mick]

On Thursday, 10 May 2018 10:48:06 BST Mick wrote:
> Hi All,
> 
> I just discovered the last nss update broke things completely on mozilla
> apps which use nss.  Firefox now refuses to connect to any site with https.
>  Trying to load google.com brings up this error message:
> 
> =
> Your connection is not secure
> 
> The website tried to negotiate an inadequate level of security.
> 
> www.google.com uses security technology that is outdated and vulnerable to
> attack. An attacker could easily reveal information which you thought to be
> safe. The website administrator will need to fix the server first before you
> can visit the site.
> 
> Error code: NS_ERROR_NET_INADEQUATE_SECURITY
> 
> 
> Have you noticed the same?

OK, looking further into this problem, it was not an update, but a downgrade 
which caused it.  I had previously keyworded nss-3.36 which yesterday fell off 
the tree and portage downgraded nss to 3.29.5.  I keyworded and emerge 3.37 
and all works as it should again.  :-)

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] dev-libs/nss-3.29.5 security level problem?

[Mick]

Hi All,

I just discovered the last nss update broke things completely on mozilla apps 
which use nss.  Firefox now refuses to connect to any site with https.  Trying 
to load google.com brings up this error message:

=
Your connection is not secure

The website tried to negotiate an inadequate level of security.

www.google.com uses security technology that is outdated and vulnerable to 
attack. An attacker could easily reveal information which you thought to be 
safe. The website administrator will need to fix the server first before you 
can visit the site.

Error code: NS_ERROR_NET_INADEQUATE_SECURITY


Have you noticed the same?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] vulkan development...

[David Haller]

Hello,

On Tue, 08 May 2018, Alan Grimes wrote:
>After playing Rise of The Tombraider using Vulkan on Gentoo I got
>inspired to try to poke with some source code. I downloaded vkQuake from
>github and tried to build it. It couldn't find ...
>
>Uh, where are the headers? What package are they in? =(

media-libs/vulkan-loader

HTH,
-dnh

-- 
Computers make very fast, very accurate mistakes.