kernel.randomize_va_space

Apparently the stock Linux kernel has an ASLR implementation. It is controlled through the kernel.randomize_va_space sysctl variable.

The values are supposedly thus (from here: http://www.win.tue.nl/~aeb/linux/hh/protection.html):

0 - don't use ASLR
1 - randomize base address for mmap'd areas
2 - ditto, and also randomize the "brk base address" (I assume that would refer to this? http://www.kernel.org/doc/man-pages/online/pages/man2/brk.2.html)

Apparently it's inferior to the GrSec implementation in that a programmer can override it, but it looks better than nothing... Or so I'd think. How does it actually compare with the Windows 7 and GrSec implementations in practice?

 

By default most of a processes address space will use ASLR on Linux with 2. The only part that wouldn't is the executable file itself, which has to be compiled as PIE. There's a significant performance hit for PIE on 32bit but virtually none for 64bit - still, Ubuntu doesn't ship with PIE on either.

What Grsecurity adds and what PaX adds is further randomization ie: more entropy for your ASLR. Furthermore it also adds exploit bruteforce prevention - a method to stop an attacker from bruteforcing the address space in order to bypass ASLR. And it's also the only implementation that implements kernel stack randomization.

Compared to windows Linux ASLR seems superior despite it's low entropy. Windows ASLR is broken - I can think of at least one static address space shared in every process and I could swear there's at least one other and probably more.

When you add PaX and Grsecurity, of course, there's no competition.

edit: Also worth noting - ASLR on a modern system with its large binaries and multiple libraries is going to be very ineffective on a 32bit address space. Brute forcing is easier because there's so much crammed into a little area. Even if you increase the entropy you're stuck in the small space. So on both platforms you're going to have easy to bypass 32bit ASLR... unless you run PaX/ Grsecurity, which not only increases randomness but also prevents bruteforcing.

 

Thanks. I guess in that case there's no point in setting it to 2 on my 32-bit netbook?

 

No, it should absolutely be set to 2. Something is very much better than nothing - while attacks can bruteforce they typically don't because it's less reliable. It's still important to have ASLR and there's no real performance hit (outside of PIE).

If you're looking for security though you want PaX/Grsecurity though. Plus you get to optimize your kernel =p always good for a netbook.

 

Ah, thanks. The distro I'm using does have fairly spotty default security, so chances are I'll be compiling a more secure kernel sometime soon.

(And this time, I'll remember to keep mprotect off. )

 

I would be wary of a distro that didn't default to 2.

 

Yes it does, at least for important root services. On my system udev, dbus, google chrome, bash, dhclient, smbd, ntp and others all have PIE executables. Granted, not everything does, but that's because PIE can break some apps (blame the app developers).

You sure about that? I think the default implementation does randomize the stack.

 

Right, yes I should have specified. For most web facing services it does. But for many services it doesnt. What I should have said is that on a default installation of Ubuntu there are many packages that do not support PIE - one very important example is Pulseaudio, which is actually a setUID binary.

Yes, an individual programs stack. But not the kernels. Every program (including the kernel) has its own stack and heap, by default only userland programs are randomized on Linux (and Windows but 8 may have changed this) but if you use PaX it extends it into the kernel.

 

Here's the list.

 

It turns out the stock Slackware kernel defaults to randomize_va_space=1. Perhaps I should mention this somewhere the devs hang out?

OTOH, the stock Slack kernel seems to be set up for maximum compatibility; one is probably expected to use a custom kernel where security is needed...

 

That's really silly. Any major package is going to support '2' at this point. It just won't compile as PIE. For a major distro that's disappointing. Even Ubuntu defaults to '2'.