Linux 4.12 To Enable KASLR By Default

[puleglot]

All this patch does is to remove four lines of text describing why hibernation will be disabled if KASLR is enabled. No other changes have been made.

Thank you, Captain Obvious! =P

[milkylainen]

It's speculation, based on an understanding of how reasonable memory allocators work. If you have relevant information to share, please educate us.

In the end, real-world benchmarks are what really count.

There are some papers about layout performance impacts like the one you are referring to.
But if done right, they are mostly negligible depending on type of randomization and if used with what type of technologies.
KASLR performance does not bother me as much as the red herring it actually is.
I remember the KASLR discussions for grsec back in 2001 and if I remember correctly they were already voicing the relative ineffectiveness of KASLR.

[DrYak]

It's speculation, based on an understanding of how reasonable memory allocators work. If you have relevant information to share, please educate us.

In the end, real-world benchmarks are what really count.

ASLR has nothing to do with memory allocation. It's about loading.
It's about putting the various pieces of the kernel in different positions at each boot.

Ex.:
Without ASLR, say there's a remote execution exploit discovered in kernel 5.69.876.
You could leverage this remote execution by sending an instruction to write to byte at address 0xcafe because that's where the privilege of the current thread is stored.
Or you could send an instruction to jump execution to address 0xdeadbeef, because that's where a useful function is located that you could use to run your shell.

(Or instead of a remote execution, it could be a buffer overflow, and you try to over flow the buffer 1034 bytes further into memory because it helps you overwrite similarly important location that happen to be stored in memory right after the buffer you're over flowing.
Or it could be a stack smash exploit, and you overwrite the return address with 0xcacacaca so the current subroutine doesn't return where it got called from, but into a location containing interesting code, etc.)

With ASLR, it won't work anymore because during loading, the various part of the kernel are loaded in different addresses each time. Things get moved around on each boot, and you can't rely on fixed addresses (or fixed relative offsets) to find the things you want to break.

The same location might be 0x1234 and 0x12345678 on your machine currently,
whereas they would be 0x4321 and 0x43218765 on my machine,
because each loaded the piece of code and data at different places.

Not only should this require random-number generation during memory allocation,

The whole point is not to put a random generator into malloc.
The whole point is not being able to know in advance which routines are loaded where in the memory of a running kernel.
Each time a kernel image is loaded from disk during boot, it ends up with a slightly different layout.

but it probably reduces cache hit-rate and likely increases heap fragmentation.

Nope.

It doesn't split various logical blocks of memory, it puts them in different position instead.

In other words : that tiny performance critical routine that gets called often will still be able to fit into memory.
It will still be e.g.:2356 bytes long, and thus still fit within a single 4k cache page.

The thing is, now this is a cached copy of the memory page that begins at address 0xbaba0000.
But on the next boot that memory page might be at address 0xdede0000

For short: block are shuffled around memory but not split.
So cache-critical pieces are still together on a micro level.
But on macro level, you have no idea where each ".ko" module got loaded.

Or another way to put it :
it's not a malloc trick.
it's a kernel decompressor and dynamic relocation call-table trick.

[cj.wijtmans]

sounds like a false sense of security. if you can read random adresses then you can also find out where these addresses are located with some "magic".

[coder]

ASLR has nothing to do with memory allocation. It's about loading.
It's about putting the various pieces of the kernel in different positions at each boot.

Thanks for clarifying that.

BTW, you didn't need to reply to my other points, once my core premise had been invalidated. The RNG and cache hit-rate concerns were entirely based on the idea of this change applying to dynamic allocation.

[coder]

sounds like a false sense of security. if you can read random adresses then you can also find out where these addresses are located with some "magic".

Of course it's not a panacea. Many exploits are write-only exploits. It's one thing to trigger a buffer overrun in some bit of code, somewhere. It's another thing, entirely, to actually poll various memory locations and get the results.

Also, although the kernel's attack surface is large (if you have access to its memory), the 64-bit address space is far larger. So, being able to probe a significant chunk of address space in a reasonable amount of time, and without segfaulting whatever process you're using to do it, is definitely not an easy thing to do.

[linuxgeex]

There are some papers about layout performance impacts like the one you are referring to.
But if done right, they are mostly negligible depending on type of randomization and if used with what type of technologies.
KASLR performance does not bother me as much as the red herring it actually is.
I remember the KASLR discussions for grsec back in 2001 and if I remember correctly they were already voicing the relative ineffectiveness of KASLR.

That's because back in 2001 the ASLR only provided 65536 variations. It was easy to hit that target at random. The argument back then was about whether per-process ASLR had any value. For example if a compromised xinetd-spawned service had a different location for the system() call, it was no harder to guess its location regardless of whether its location was randomized at link time.

The landscape has changed a bit since back then. Most notably we have hardware randomization and the 48-bit address space of x86-64 provides a lot more hiding places.

Some argue that ASLR is "security by obscurity" and that automatically dooms it to failure. That's empty rhetoric far as I'm concerned... all security can be seen as "security by obscurity" once you accept that all true security is based on capabilities, and then accept that all capabilities boil down to whether or not a certain thing is known, and the odds of guessing what that thing is. Then you must recognize that the true measure of your security is the time it takes to beat the odds with an educated or brute-force guess. A lock is only as strong as the delay it provides before it is picked. ASLR adds some time. Its not a silver bullet but that doesn't stop it being a good thing.

[linuxgeex]

Of course it's not a panacea. Many exploits are write-only exploits. It's one thing to trigger a buffer overrun in some bit of code, somewhere. It's another thing, entirely, to actually poll various memory locations and get the results.

Also, although the kernel's attack surface is large (if you have access to its memory), the 64-bit address space is far larger. So, being able to probe a significant chunk of address space in a reasonable amount of time, and without segfaulting whatever process you're using to do it, is definitely not an easy thing to do.

x86-64 only uses 48 bits currently. That's a hardware limitation of all available current x86-64 processors. Intel is working on extending that to 57 bits. See the recent article about 5th level paging. Segfaulting isn't always a roadblock. For a local exploit it's no issue at all. For a remote exploit, any service that forks per request can segfault thousands of times per second, and so far I've never seen anything(similar to Fail2Ban) which watches for segfaults and firewalls attacker IPs. I've never seen a service which reports the connected IP when it segfaults. It's not impossible... it's just not done.

[DrYak]

Some argue that ASLR is "security by obscurity"

Quite difficult to call it so.
"Security by obscurity" is security by "you have no idea how this thing work". (i.e.: the algorithm itself is secret). Unlike modern cryptography which employs widely known and well reviewed building blocks (e.g: AES), and the only thing which is secret is a paremeter (like the password), not the whole algorithm it self.

Here again, the whole randomisation is documented (with the kernel being GPL).
The only thing which is unknown (to an external attacker) is the randomization parameter.

It's yet another thing that an attacker has to guess.
(e.g.: to which alternative return address should the code jump to, in case of stack overwriting ?)

It's brute-forceable (e.g: as mentionned above, a fork-able process can be crashed a great many times), but it's a thing that the attacker must know brute force, instead of just relying on a fixed address.

For a remote exploit, any service that forks per request can segfault thousands of times per second, and so far I've never seen anything(similar to Fail2Ban) which watches for segfaults and firewalls attacker IPs. I've never seen a service which reports the connected IP when it segfaults. It's not impossible... it's just not done.

That would be cool.
But that would indeed require some development:
i.e.: adding logging which fork has taken request from which IP,
and multi line fail2ban matcher that can match a "request IP given to fork {PID}" line and a "segfault in {PID}" many-line down in the log.

But would be definitely cool.

[Serafean]

ASLR is "undoable" through Chrome using javascript... No idea how this is applicable to the kernel.

https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf

https://www.cs.vu.nl/~herbertb/download/papers/revanc_ir-cs-77.pdf