Re: kernel aslr: someone interested?

[Joerg Sonnenberger]

On Sat, Mar 25, 2017 at 10:17:21PM -0400, Mouse wrote:
> > [ASLR] is just one more check mark in the exploit building tool.
> 
> Yes and no.
> 
> It increases the work required to exploit any putative bugs.

Please read the constraints again. There are very few RCE against the
kernels. The normal and reasonable assumption is the ability to execute
local code. If you can execute local code, you can silently defeat
kernel ASLR. Silently in the sense that all it requires is less than one
hour of computation, but without otherwise doing suspicious activity.
It is not harder in any combinatorial sense, i.e. it is additive
overhead. That's quite different from the typical attack scenario for a
server.

Joerg

Re: kernel aslr: someone interested?

[Mouse]

> [ASLR] is just one more check mark in the exploit building tool.

Yes and no.

It increases the work required to exploit any putative bugs.  It does
not make exploitation impossible, but that does not mean it's not worth
making it harder.  "You don't have to run faster than the bear; you
just have to run faster than someone else."  That is, you don't have to
be impossible to exploit; you just have to be enough harder to make
them go after someone else instead.

I wonder if there's some way to do it that allows you to change offsets
on the fly.  It may well be a pipe dream, but, if you could relocate
everything in kernel space periodically, say, every second, it could
_significantly_ increase the work factor for exploitation.

/~\ 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: kernel aslr: someone interested?

[Christos Zoulas]

In article ,
Greg Troxel   wrote:
>-=-=-=-=-=-
>
>
>Maxime Villard  writes:
>
>> I would also add - even if it is not a relevant argument - that most
>> "commonly-used" operating systems do have kernel aslr: Windows, Mac, Linux,
>> etc.
>
>There's another point, which various people may also consider invalid :-)
>
>In the US, there's a federal computer security standard NIST 800-53, and
>essentially a subset of that NIST 800-171, and more or less all federal
>contractors handling non-public information have to implement it.  There
>are a lot of security controls, and exploit mitigation is one of them.
>
>I am not claiming that kernel ASLR is a requirement.  But, I would hate
>to see people in these environments be told not to use NetBSD because it
>lacks some security controls compared to alternatives.

I think that nobody disputes that ASLR significantly raises the barrier
to entry (amount of work) that attackers need to perform in most cases.

christos

Re: kernel aslr: someone interested?

[Joerg Sonnenberger]

On Sat, Mar 25, 2017 at 11:22:24AM -0400, Thor Lancelot Simon wrote:
> ASLR increases the work factor for that stuff considerably (though there
> are obvious approaches if you can zap the early boot code to wire down
> the "randomization" so it isn't, etc).

I strongly contend this point in the case of the kernel and under the
assumption that the attacker can execute (unprivileged) code. The
approach can be found, i.e. see 33C3. I also strongly question any magic
fixes from vendors -- it is highly unlikely to work by the very nature
of how caches and the TLB operate. So yes, it strongly seems to me that
the consensus in the security research community is that kernel ASLR
doesn't really work on modern CPUs.

Joerg

Re: kernel aslr: someone interested?

[Maxime Villard]

Le 25/03/2017 à 13:35, Joerg Sonnenberger a écrit :

I don't think *any* of the cache latency problems have been fixed at
all.


Yes, they haven't been fixed yet, but are being. I remember reading that
AMD was working on fixing that - I'll have to refind the article though.


They are highly unlikely to be fixed as it would significantly
impact performance and if CPUs have one design focus after correctness,
it is performance. Some what I have seen, the consensus is that kernel
ASLR can be considered ineffective for the text segment at the very
least and many parts of the data structures as well as long as the
attacker can execute (unprivileged) instructions on the CPU at will.


I don't quite understand what your point is. Correctness today also means
security, and in the recent years Intel and AMD have introduced many
features that they could have implemented twenty years ago (SMEP, SMAP,
UMIP, PKE, etc.).

None of us knows precisely how circuitry works on modern CPUs, and the
fact that in "cache latency" there is "cache" does not necessarily mean
that fixing it implies reducing performance. You can be sure that SMEP
adds some overhead on each instruction executed in kernel mode, but it
is a legitimate cost.


As such, the point of "it makes bugs harder to exploit" is effectively
false -- if you can force either the code path of interesting to be
executed or any code path with a known offset, there is a generic method
to compute the necessary address. It is just one more check mark in the
exploit building tool.


? If there is a known offset you can do what you want, but the point is
precisely to randomize this offset. And yes, it does make bugs harder to
exploit, just like any form of ASLR available out there.


There is a lot more effort involved than just providing an
implementation. Just as it was easy to make everything PIE with ASLR
without really caring about the fallout it creates in pkgsrc.


I disagree. You are comparing pkgsrc - which contains thousands of
potentially buggy packages written by many different people and
organizations, several of which do not exist anymore and do not fix their
buggy code - and the kernel, which is a simple software we edit.

If there is a fallout, I'll just fix it, and end of story.


What is
the impact kernel ASLR has debugability, performance and stability of
performance? At least for the first item on the list, it will be pain.


In your list, I would have put performance first. There is almost no
impact on debugability: the symbols [1] remain in place, and the kernel
is relocated from there, so ddb can find the addresses just like on a
static kernel. Stability of performance does not change either.

What does change is the performance, and in this case it depends on how
we compile the kernel as PIE. ASLR would likely result in longer
instructions, slower to execute by the CPU. But as I said, many systems
support kernel aslr, and if the performance regression was that terrible
they wouldn't have enabled it.

Generally speaking, I would say that you are again using the same argument:
"things are black, we can't make them totally white, so no point in making
them grey". I could almost copy-paste the last paragraph of this mail [2]
I sent you a year ago, because you were already using the exact same
argument. Yes, security features aren't all perfect, but they remain
useful, regardless of whether you like them or not. Kernel ASLR is becoming
increasingly interesting and efficient, and that's almost a fact of life.


This time I insist, so if someone is interested, please let me know.


[1] https://nxr.netbsd.org/xref/src/sys/lib/libsa/loadfile_elf32.c#262
[2] http://mail-index.netbsd.org/tech-kern/2016/07/29/msg020924.html

Re: kernel aslr: someone interested?

[Maxime Villard]

Le 25/03/2017 à 08:25, Martin Husemann a écrit :

On Fri, Mar 24, 2017 at 11:13:34PM +0100, Joerg Sonnenberger wrote:

For what purpose? It has been shown over and over again that ASLR simply
doesn't work in a lot of situations in userland. The situation for
kernel ASLR is significantly worse. From a security standpoint, it
doesn't seem to be worth the effort. Now, there are cases on some
architectures where a relocatable kernel would be useful, but that's a
quite a bit different from ASLR.


IMHO the more interesting question is whether we can randomize some of the
VA layout the kernel enforces, which is far beyound simple ASLR (and
orthogonal).


On amd64 it is not a very big deal, and I think I can handle that.

Re: kernel aslr: someone interested?

[Thor Lancelot Simon]

On Sat, Mar 25, 2017 at 09:20:14AM +0100, Maxime Villard wrote:
> 
> Verily, 5-level page trees with higher entropy will be introduced by Intel
> soon, the instructions that leak kernel addresses can be made privileged
> (UMIP), cache issues are being fixed; and in short, I wouldn't be surprised
> if in five years other features appear that make ASLR even more interesting
> and faster than static code.

I would, since "static code" is clearly the base case for any address layout
scheme.  But once you're within a smidge, who cares?

Even now, with register renaming and every other trick in the book and
*without* ASLR, PIC is still measurably slower than non-PIC in userland.
Not much, but try it and see (on modern CPUs you'll need the performance
counters, I suspect -- thanks for fixing those).  But nobody seems to
notice enough to build non-PIC, so...

Obviously on VAC platforms ASLR is unacceptably slow.  But there aren't
many of those left, and we don't build every platform with the same
toolchain options anyway (of course).

Everyone else that matters has begun to move towards ASLR as the default
(many, perhaps most, are there for userspace code already) and it _does_
matter -- if Max's vault7 example doesn't suffice, have a look at those
ShadowBrokers firewall exploits that were released a few months back.
Each and every one of those comes in several different flavors tweaked
for the kernel layout of different versions of the same code on the same
platform -- where there are instructions for use (fun to read) they
basically say to stop attacking and get expert help if you run into a
target where the -- *static* -- kernel layout is unexpected.  ASLR
increases the work factor for that stuff considerably (though there
are obvious approaches if you can zap the early boot code to wire down
the "randomization" so it isn't, etc).  Yes, there are workloads where
we wouldn't want it, but I submit there are also many important
cases where we should have it.

Thor

Re: kernel aslr: someone interested?

[Joerg Sonnenberger]

On Sat, Mar 25, 2017 at 09:20:14AM +0100, Maxime Villard wrote:
> Le 24/03/2017 à 23:13, Joerg Sonnenberger a écrit :
> > On Thu, Mar 23, 2017 at 06:30:31PM +0100, Maxime Villard wrote:
> > > I have some plans to implement kernel aslr on amd64.
> > 
> > For what purpose? It has been shown over and over again that ASLR simply
> > doesn't work in a lot of situations in userland. The situation for
> > kernel ASLR is significantly worse.
> 
> But it does not alter the fact that each situation is being fixed. When
> it comes to kernel ASLR, five years ago a lot of people could have said
> that the number of bits available to randomize the VA space is too small,
> that several unprivileged instructions leak some memory locations, that
> cache latency gives hints about where the kernel text is, etc.

I don't think *any* of the cache latency problems have been fixed at
all. They are highly unlikely to be fixed as it would significantly
impact performance and if CPUs have one design focus after correctness,
it is performance. Some what I have seen, the consensus is that kernel
ASLR can be considered ineffective for the text segment at the very
least and many parts of the data structures as well as long as the
attacker can execute (unprivileged) instructions on the CPU at will.
As such, the point of "it makes bugs harder to exploit" is effectively
false -- if you can force either the code path of interesting to be
executed or any code path with a known offset, there is a generic method
to compute the necessary address. It is just one more check mark in the
exploit building tool.

> > ... it doesn't seem to be worth the effort.
> 
> Well, I've already made most of the effort required, I'm just stuck with
> makefiles and toolchains. If really no one is interested in that,
> developing my prekern has been at least an interesting technical challenge.

There is a lot more effort involved than just providing an
implementation. Just as it was easy to make everything PIE with ASLR
without really caring about the fallout it creates in pkgsrc. What is
the impact kernel ASLR has debugability, performance and stability of
performance? At least for the first item on the list, it will be pain.
At the same time, even many developers from the systems you have
mentioned find it to be ineffective.

Joerg

Re: kernel aslr: someone interested?

[Greg Troxel]

Maxime Villard  writes:

> I would also add - even if it is not a relevant argument - that most
> "commonly-used" operating systems do have kernel aslr: Windows, Mac, Linux,
> etc.

There's another point, which various people may also consider invalid :-)

In the US, there's a federal computer security standard NIST 800-53, and
essentially a subset of that NIST 800-171, and more or less all federal
contractors handling non-public information have to implement it.  There
are a lot of security controls, and exploit mitigation is one of them.

I am not claiming that kernel ASLR is a requirement.  But, I would hate
to see people in these environments be told not to use NetBSD because it
lacks some security controls compared to alternatives.


signature.asc
Description: PGP signature

Re: kernel aslr: someone interested?

[Maxime Villard]

Le 24/03/2017 à 23:13, Joerg Sonnenberger a écrit :

On Thu, Mar 23, 2017 at 06:30:31PM +0100, Maxime Villard wrote:

I have some plans to implement kernel aslr on amd64.


For what purpose? It has been shown over and over again that ASLR simply
doesn't work in a lot of situations in userland. The situation for
kernel ASLR is significantly worse.


But it does not alter the fact that each situation is being fixed. When
it comes to kernel ASLR, five years ago a lot of people could have said
that the number of bits available to randomize the VA space is too small,
that several unprivileged instructions leak some memory locations, that
cache latency gives hints about where the kernel text is, etc.

Verily, 5-level page trees with higher entropy will be introduced by Intel
soon, the instructions that leak kernel addresses can be made privileged
(UMIP), cache issues are being fixed; and in short, I wouldn't be surprised
if in five years other features appear that make ASLR even more interesting
and faster than static code.

I would also add - even if it is not a relevant argument - that most
"commonly-used" operating systems do have kernel aslr: Windows, Mac, Linux,
etc.


From a security standpoint ...


It does make many bugs harder to exploit. The security advisory that was
published yesterday for example (about a privilege escalation bug in Xen)
would have been a lot more difficult to exploit if the kernel VA had been
randomized; currently you only need to readelf the kernel, get the address
of the sysent structure, and simply patch it.

If you look for, you can see in the Vault7 leak that the CIA was trying to
disassemble a custom NetBSD kernel to see where the text segment is
located in memory; so it's not like no one gives a damn about kernel aslr.


... it doesn't seem to be worth the effort.


Well, I've already made most of the effort required, I'm just stuck with
makefiles and toolchains. If really no one is interested in that,
developing my prekern has been at least an interesting technical challenge.

Re: kernel aslr: someone interested?

[Martin Husemann]

On Fri, Mar 24, 2017 at 11:13:34PM +0100, Joerg Sonnenberger wrote:
> For what purpose? It has been shown over and over again that ASLR simply
> doesn't work in a lot of situations in userland. The situation for
> kernel ASLR is significantly worse. From a security standpoint, it
> doesn't seem to be worth the effort. Now, there are cases on some
> architectures where a relocatable kernel would be useful, but that's a
> quite a bit different from ASLR.

IMHO the more interesting question is whether we can randomize some of the
VA layout the kernel enforces, which is far beyound simple ASLR (and
orthogonal).

Martin