Re: Spectre

[maya]

It's a lot less obvious from a CPU designer perspective. One will make
the speculative bits, declare 'all the actions I do are rolled back, so
this is perfectly safe!' and someone else making the cache doesn't
realize that the reads were speculative and their effects should have
been rolled back.

People were talking about timing attacks for a while, but somehow it
hadn't clicked that:
  array[*malicious_address & 1]

Actually leaks (via timing) the content of the first bit of
malicious_address.

Or maybe it's just hadn't for me.

Re: Spectre

[Mouse]

> Spectre is unrelated and does not depend on a mistake of this kind,
> since there you're dealing with speculative loads that ARE permitted
> as far as access control goes; they just aren't wanted because they
> are preceded by range checks or the like.

Yes.  I'm of two minds whether it's even fair to call spectre variants
like that a vulnerability.  (Spectre variants that exfiltrate values
from other processes, or from the kernel, are quite another story.)

On the one hand, of course, it is, in that it can be used to do things
like read outside sandboxes.

But, on the other hand, I can easily imagine a CPU designer looking at
it and saying "What's the big deal if this code can read that location?
It can get it anytime it wants with a simple load instruction anyway.",
something I have trouble disagreeing with.

So, I'm not sure whether I consider those spectre variants a CPU bug or
just a misfeature that makes sandboxing more difficult (in that it
provides unobvious ways to read memory).

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Spectre

[maya]

On Thu, Jan 18, 2018 at 12:37:11AM +, co...@sdf.org wrote:
> - Variant 1 seems possible to avoid with low cost. It will likely result
>   in an error somewhere along the line, which is detectable. Flushing
>   the entire cache on userret will make it hard to exploit. Do all
>   bound checks failing result in an easily noticed error?

On further thought, this won't be sufficient protection.
It only protects assuming we:
- Cache memory
- Time access to memory
- Flush cache
- Time access to now cached memory

Flushing on userret/kernel entry is not sufficient because I am assuming
it will need a second trip to userland. it does not, assuming we can
construct our own perfect gadget.

Re: /dev/ksyms permissions

[maya]

On Wed, Jan 17, 2018 at 07:19:32PM +0100, Anders Magnusson wrote:
> libkvm uses it to get the kernel symbol namelist instead of reading /netbsd
> for it (originally kvmdb, which was retired when ksyms was added).
> Programs like ps, netstat etc... uses it to find in-kernel stuff, so you
> cannot change it to require root privs to be read.
> Maybe group kmem read, but that might require more elevated privileges in
> the programs that uses ksyms.

Thanks for the heads up. I was wondering if I missed an obvious non-root
user.

Re: Spectre

[maya]

On Wed, Jan 17, 2018 at 08:08:06PM -0500, Mouse wrote:
> Unfortunately, they appear to be exported only on the Web, and even
> then only over HTTPS.  I can send copies privately to anyone for whom
> those are obstacles (probably not very many, but they were for me).
> https://spectreattack.com/ and https://meltdownattack.com/ are the URLs
> I've found, though (as implied above) I haven't actually verified them
> myself.

Hi Mouse,

'wget -r' is often effective at fetching the contents of websites.
It handles this website. If the problem is the website it might help.

Re: Spectre

[Paul.Koning]

> On Jan 17, 2018, at 8:08 PM, Mouse  wrote:
> 
> ...
>> - Even speculative execution obeys access restrictions,
> 
> In some respects.  Meltdown is possible because Intel spec ex does not
> obey access restrictions in one particular respect; I don't know what
> aspects may not be obeyed by what CPUs except for that.

Indeed.  I was surprised, but apparently that "obeys..." is wrong in
the case of Intel, though it is correct, as you might expect, for AMD
and ARM and probably most other architectures.

More precisely, speculative execution obeys access restrictions in
the sense that no architecturally visible (i.e., register/memory)
changes occur that are prohibited by the access controls.  But Intel
does launch a speculative load without checking access; apparently
the access check is done in parallel and will complete a while later,
by which time the speculatively loaded data is in the cache and some
other operations may be done based on it.

Obviously, if speculative loads check permissions prior to launching
the load, the issue goes away.  If so, Meltdown is completely 
prevented.

Spectre is unrelated and does not depend on a mistake of this kind,
since there you're dealing with speculative loads that ARE permitted
as far as access control goes; they just aren't wanted because they
are preceded by range checks or the like.

paul

Re: Spectre

[Mouse]

> 

I'd suggest reading the papers describing spectre and meltdown.  They
are fairly readable - I would expect anyone working on the NetBSD
kernel to be competent to understand them - and they describe the
vulnerabilities, and how the authors exploited them, in reasonable
detail.

Unfortunately, they appear to be exported only on the Web, and even
then only over HTTPS.  I can send copies privately to anyone for whom
those are obstacles (probably not very many, but they were for me).
https://spectreattack.com/ and https://meltdownattack.com/ are the URLs
I've found, though (as implied above) I haven't actually verified them
myself.

> Spectre is also a vulnerability.

> - Even speculative execution obeys access restrictions,

In some respects.  Meltdown is possible because Intel spec ex does not
obey access restrictions in one particular respect; I don't know what
aspects may not be obeyed by what CPUs except for that.

> - Variant 1 seems possible to avoid with low cost. It will likely
>   result in an error somewhere along the line, which is detectable.

Sometimes.

Doing the operation inside a transaction apparently will suppress the
memory fault in at least some cases.

Executing the whole thing under spec ex of a mispredicted branch
definitely will annul the trap, but, from reading the papers, it
appears they haven't tested it, so it's speculation (hah), albeit
reasonable speculation, that it would be exploitable that way.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Spectre

[maya]

On Thu, Jan 18, 2018 at 12:37:11AM +, co...@sdf.org wrote:
> - Intel and AMD have pushed microcode updates that introduce
>   instructions, for Intel they are 'IBPB' and 'IBRS'.

+ STIBP for Intel.

> - I'm not sure how easy it is to find a good enough gadget without
>   something like eBPF

Lua is probably a good target (though we don't normally have it loaded).

Spectre

[coypu]

Hi folks.



Spectre is also a vulnerability. It's been discussed in the context of
web browsers, but it does have repercussions for kernel.

The gist of it seems to be, if you have code that looks like this:

Variant 1:

if (malicious offset is safe)
  value  = array[malicious_offset];
  value2 = (value & 1)
  value3 = array2[value2]

You can read arbitrary memory, as cached memory will be faster. repeat
this bit by bit.

Variant 2:
relies on poisoning the branch predictor

if_transmit = mydriver_transmit;
..

  regular code
  if_transmit(); /* indirect call */
..

malicious_ptr:
  value  = array[malicious_offset];
  value2 = (value & 1)
  value3 = array2[value2]

Now, we poison the branch target buffer, to predict that
if_transmit = malicious_ptr.

It does not even appear like a possible code path, but it is.
This means that code being loaded is enough to pose a risk, even if
there is no easy path to it.


Some things that help this:
- Rather than look for a gadget like this, they went for eBPF, which is
  like dtrace. It also has a JIT. You can load bytecode and it will
  verify and execute it. So you can make your own speculation-gadget.

- Some archs do not allow fine-grained cache control like x86 clflush,
  but this isn't necessary for abuse. just fill the cache before going.
  they have done similar from JavaScript.

Some that harm it:
- Even speculative execution obeys access restrictions, so SMEP, SMAP,
  marking memory NX will prevent execution.

- Instructions like 'lfence' stop speculative execution.

- Intel and AMD have pushed microcode updates that introduce
  instructions, for Intel they are 'IBPB' and 'IBRS'.

- ARM has 'BPIALL' to invalidate the branch target to stop branch
  predictor poisoning

- Retpoline, stuff_RSB etc. to modify jumps to be less likely to jump
  into user-controlled code.

People seemed to occasionally mentioned that 'as many as 100
instructions will be executed speculatively', so that is how far we are
talking.


Own thoughts:
- Variant 1 seems possible to avoid with low cost. It will likely result
  in an error somewhere along the line, which is detectable. Flushing
  the entire cache on userret will make it hard to exploit. Do all
  bound checks failing result in an easily noticed error?

- Variant 2 however is harder without custom instructions. Those may
  rely on a CPU being new enough to receive microcode updates, and
  them being applied.

- I'm not sure how easy it is to find a good enough gadget without
  something like eBPF, but the mere presence of the code in memory was a
  risk.

- Linux could've marked eBPF non-executable when it is unused, so its
  presence in memory does not pose risk.



Discuss.

Re: amd64: kernel aslr support

[Thomas Klausner]

On Wed, Jan 17, 2018 at 08:01:19AM +0100, Maxime Villard wrote:
> Or, you can dump the location of the segments by loading a kernel module
> that calls the following function
...
> It will give you the addresses of the pages containing the kernel sections.
> Note however that the sections may not start exactly at the printed addresses,
> they are shifted.

Thanks, that worked. I've attached the kernel module I wrote (put it
in src/sys/modules/aslr_test).

Here's the output:

GENERIC:
Segment 0 (text): va=0x8020 size=12582912
Segment 1 (rodata): va=0x80e0 size=6291456
Segment 2 (data): va=0x8140 size=8388608

KASLR, boot 1
Segment 0 (text): va=0xc340 size=2097152
Segment 1 (rodata): va=0xfa0ec000 size=4096
Segment 2 (rodata): va=0xf5e0 size=2097152
Segment 3 (rodata): va=0xbd80 size=2097152
Segment 4 (rodata): va=0x9fb39000 size=4096
Segment 5 (rodata): va=0xa12a6000 size=4096
Segment 6 (rodata): va=0xd7872000 size=4096
Segment 7 (rodata): va=0xe37e2000 size=4096
Segment 8 (rodata): va=0xa4f15000 size=4096
Segment 9 (rodata): va=0xcb613000 size=4096
Segment 10 (rodata): va=0xbf82a000 size=4096
Segment 11 (rodata): va=0x95414000 size=4096
Segment 12 (rodata): va=0xbf8f1000 size=4096
Segment 13 (rodata): va=0xa0fa2000 size=4096
Segment 14 (rodata): va=0x835b5000 size=4096
Segment 15 (data): va=0xf8c0 size=2097152
Segment 16 (data): va=0x8d00 size=2097152
Segment 17 (data): va=0xe300 size=2097152
Segment 18 (data): va=0xa5e0 size=2097152
Segment 19 (text): va=0xff80 size=2097152
Segment 20 (text): va=0xc3a0 size=2097152
Segment 21 (text): va=0x9d40 size=2097152
Segment 22 (text): va=0xc360 size=2097152
Segment 23 (text): va=0xca80 size=2097152
Segment 24 (text): va=0xe8e0 size=2097152
Segment 25 (text): va=0xc5e0 size=2097152
Segment 26 (text): va=0xf6a0 size=2097152
Segment 27 (text): va=0xec80 size=2097152
Segment 28 (text): va=0xc660 size=2097152
Segment 29 (text): va=0x85a0 size=2097152
Segment 30 (rodata): va=0xdb00 size=2097152
Segment 31 (rodata): va=0xfac0 size=2097152
Segment 32 (rodata): va=0x8e60 size=2097152
Segment 33 (rodata): va=0xb840 size=2097152
Segment 34 (rodata): va=0x9440 size=2097152

KASLR, boot 2
Segment 0 (text): va=0xb700 size=2097152
Segment 1 (rodata): va=0xc1b36000 size=4096
Segment 2 (rodata): va=0xc740 size=2097152
Segment 3 (rodata): va=0xe7e0 size=2097152
Segment 4 (rodata): va=0x93453000 size=4096
Segment 5 (rodata): va=0xa426 size=4096
Segment 6 (rodata): va=0x862c7000 size=4096
Segment 7 (rodata): va=0xd8681000 size=4096
Segment 8 (rodata): va=0xaec34000 size=4096
Segment 9 (rodata): va=0xdba5e000 size=4096
Segment 10 (rodata): va=0x8e14c000 size=4096
Segment 11 (rodata): va=0xb2cbc000 size=4096
Segment 12 (rodata): va=0xa5a5e000 size=4096
Segment 13 (rodata): va=0xdc716000 size=4096
Segment 14 (rodata): va=0x96f8b000 size=4096
Segment 15 (data): va=0xd1e0 size=2097152
Segment 16 (data): va=0xcec0 size=2097152
Segment 17 (data): va=0xec40 size=2097152
Segment 18 (data): va=0xc3e0 size=2097152
Segment 19 (text): va=0x92c0 size=2097152
Segment 20 (text): va=0x8c20 size=2097152
Segment 21 (text): va=0x9a20 size=2097152
Segment 22 (text): va=0xa460 size=2097152
Segment 23 (text): va=0xe9a0 size=2097152
Segment 24 (text): va=0xab60 size=2097152
Segment 25 (text): va=0xd3c0 size=2097152
Segment 26 (text): va=0x8340 size=2097152
Segment 27 (text): va=0xf120 size=2097152
Segment 28 (text): va=0xd240 size=2097152
Segment 29 (text): va=0xc900 size=2097152
Segment 30 (rodata): va=0xaf80 size=2097152
Segment 31 (rodata): va=0xacc0 size=2097152
Segment 32 (rodata): va=0xae60 size=2097152
Segment 33 (rodata): va=0xf160 size=2097152
Segment 34 (rodata): va=0xad00 size=2097152

> > Why does GENERIC_KASLR disable KDTRACE_HOOKS? Is this necessary, or
> > are KDTRACE_HOOKS lowering the security somehow?
> 
> In fact, it's because KDTRACE_HOOKS wants to parse one CTF section; but with
> our implementation we have several of them, and KDTRACE_HOOKS does not
> handle that.

Chuck's patch for better ZFS/DTRACE support includes parsing of
multiple CTF sections, intended for use with kernel modules (so that
each kernel module can include its CTF). Will that be sufficient for
KASLR?

Thanks,
 Thomas
# $NetBSD: Makefile,v 1.1 

Re: /dev/ksyms permissions

[Anders Magnusson]

Den 2018-01-17 kl. 20:20, skrev Mouse:

Maybe group kmem read, but that might require more elevated
privileges in the programs that uses ksyms.

What program uses ksyms now that doesn't require at least group kmem?

You cannot give up kmem read privileges when calling ksyms read
routines.

I don't see why not - or, at least, I don't see the ksyms change as
being relevant.  Just read /dev/ksyms at startup (at the same time as
you open /dev/kmem, probably), before dropping group kmem.  Isn't that
all this change (making /dev/ksyms 440 root:kmem) requires?

You still have to call library functions with elevated privileges compared
with today.  May not be a big problem, but the code should be audited first
and this behaviour documented.

-- Ragge

Re: /dev/ksyms permissions

[Mouse]

>>> Maybe group kmem read, but that might require more elevated
>>> privileges in the programs that uses ksyms.
>> What program uses ksyms now that doesn't require at least group kmem?
> You cannot give up kmem read privileges when calling ksyms read
> routines.

I don't see why not - or, at least, I don't see the ksyms change as
being relevant.  Just read /dev/ksyms at startup (at the same time as
you open /dev/kmem, probably), before dropping group kmem.  Isn't that
all this change (making /dev/ksyms 440 root:kmem) requires?

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: /dev/ksyms permissions

[Anders Magnusson]

Den 2018-01-17 kl. 20:03, skrev Mouse:



Maybe group kmem read, but that might require more elevated
privileges in the programs that uses ksyms.

What program uses ksyms now that doesn't require at least group kmem?


You cannot give up kmem read privileges when calling ksyms read routines.
Think setegid().

-- Ragge

Re: /dev/ksyms permissions

[Mouse]

> libkvm uses it to get the kernel symbol namelist instead of reading
> /netbsd for it (originally kvmdb, which was retired when ksyms was
> added).  Programs like ps, netstat etc... uses it to find in-kernel
> stuff, so you cannot change it to require root privs to be read.

But the symbol values are useless except for reading kernel memory (and
kernel-side debugging, which latter I think we can assume can assume
root access for).  So I see no harm changing /dev/ksyms to be 440
root:kmem.  (I don't _like_ it, and would configure my own systems
otherwise, but that's for much the same reasons I dislike kaslr, which
are fairly specific to my use aptterns.)

> Maybe group kmem read, but that might require more elevated
> privileges in the programs that uses ksyms.

What program uses ksyms now that doesn't require at least group kmem?

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: /dev/ksyms permissions

[Christos Zoulas]

In article <20180117152524.ga11...@sdf.org>,   wrote:
>-=-=-=-=-=-
>
>This leaks information that unprivileged user probably has no reason to
>own:
>
>> cat /dev/ksyms > ksyms
>> readelf -a ksyms |wc -l
>   47594
>
>Any strong reason not to apply the following?
>Presumably it will have benefits for GENERIC_KASLR, or people with
>Intel CPUs :-)
>
>-=-=-=-=-=-
>
>Index: MAKEDEV.tmpl
>===
>RCS file: /cvsroot/src/etc/MAKEDEV.tmpl,v
>retrieving revision 1.189
>diff -u -r1.189 MAKEDEV.tmpl
>--- MAKEDEV.tmpl   9 Jan 2018 03:31:14 -   1.189
>+++ MAKEDEV.tmpl   17 Jan 2018 15:19:04 -
>@@ -933,7 +933,7 @@
>   mkdev   fullc %mem_chr% 11  666
>   mkdev   zeroc %mem_chr% 12  666
>   mkdev   klogc %log_chr% 0   600
>-  mkdev   ksyms   c %ksyms_chr% 0 444
>+  mkdev   ksyms   c %ksyms_chr% 0 400
>   mkdev   random  c %rnd_chr% 0   444
>   mkdev   urandom c %rnd_chr% 1   644
>   if ! $fdesc_mounted; then

Perhaps 440 $g_kmem, if you don't want to break the world :-)

christos

Re: /dev/ksyms permissions

[Anders Magnusson]

libkvm uses it to get the kernel symbol namelist instead of reading 
/netbsd for it (originally kvmdb, which was retired when ksyms was added).
Programs like ps, netstat etc... uses it to find in-kernel stuff, so you 
cannot change it to require root privs to be read.
Maybe group kmem read, but that might require more elevated privileges 
in the programs that uses ksyms.


-- Ragge

Den 2018-01-17 kl. 16:25, skrev co...@sdf.org:

This leaks information that unprivileged user probably has no reason to
own:


cat /dev/ksyms > ksyms
readelf -a ksyms |wc -l

47594

Any strong reason not to apply the following?
Presumably it will have benefits for GENERIC_KASLR, or people with
Intel CPUs :-)

/dev/ksyms permissions

[coypu]

This leaks information that unprivileged user probably has no reason to
own:

> cat /dev/ksyms > ksyms
> readelf -a ksyms |wc -l
   47594

Any strong reason not to apply the following?
Presumably it will have benefits for GENERIC_KASLR, or people with
Intel CPUs :-)
Index: MAKEDEV.tmpl
===
RCS file: /cvsroot/src/etc/MAKEDEV.tmpl,v
retrieving revision 1.189
diff -u -r1.189 MAKEDEV.tmpl
--- MAKEDEV.tmpl9 Jan 2018 03:31:14 -   1.189
+++ MAKEDEV.tmpl17 Jan 2018 15:19:04 -
@@ -933,7 +933,7 @@
mkdev   fullc %mem_chr% 11  666
mkdev   zeroc %mem_chr% 12  666
mkdev   klogc %log_chr% 0   600
-   mkdev   ksyms   c %ksyms_chr% 0 444
+   mkdev   ksyms   c %ksyms_chr% 0 400
mkdev   random  c %rnd_chr% 0   444
mkdev   urandom c %rnd_chr% 1   644
if ! $fdesc_mounted; then