Address Space Layout Randomization (ASLR) was first implemented in Linux in 2001 and formally included in Linux kernel 2.6.12 in 2005. Microsoft followed soon afterwards and implemented ASLR in Vista in 2007.
ASLR randomizes process memory address space in order to prevent an attacker from finding the addresses of functions or ROP (Return Oriented Programming) gadgets required to successfully complete an exploit. The effectiveness of ASLR is limited by the amount of available entropy which varies from platform to platform depending on the implementation.
For ASLR to be useful, all segments of a processes memory space must be randomized. If even a single area of process memory is not randomized, ASLR can be defeated because an attacker could use that single area to discover useful ROP gadgets with which to build a successful exploit.
Address space randomization is used to hinder some types of attacks by making it more difficult for an attacker to predict target addresses. For example, attackers trying to execute return-to-libc or ROP gadget attacks must first locate the code to be executed, whereas attackers trying to execute shellcode injected on the stack must first find the appropriate SP and IP. Even NOP sleds have limitations!
Window binaries have to be specifically built with ALSR enabled, and all required DLLs must also have been built with ALSR enabled, for ALSR to be effective on a Windows platform. In many cases people build applications with ASLR enabled but include pre-built DLLs which are not ASLR-enabled. This totally defeats the purpose of ASLR.
By default, Linux binaries and shared objects are build with ASLR enabled except for the .text segment, i.e. the program code. The .text segment is only randomized if the program is build as a Position Independent Executable (PIC).
ASLR can be configured via /proc/sys/kernel/randomize_va_space. From the kernel documentation:
randomize_va_space:
This option can be used to select the type of process address
space randomization that is used in the system, for architectures
that support this feature.
0 - Turn the process address space randomization off. This is the
default for architectures that do not support this feature anyways,
and kernels that are booted with the "norandmaps" parameter.
1 - Make the addresses of mmap base, stack and VDSO page randomized.
This, among other things, implies that shared libraries will be
loaded to random addresses. Also for PIE-linked binaries, the
location of code start is randomized. This is the default if the
CONFIG_COMPAT_BRK option is enabled.
2 - Additionally enable heap randomization. This is the default if
CONFIG_COMPAT_BRK is disabled.
There are a few legacy applications out there (such as some ancient
versions of libc.so.5 from 1996) that assume that brk area starts
just after the end of the code+bss. These applications break when
start of the brk area is randomized. There are however no known
non-legacy applications that would be broken this way, so for most
systems it is safe to choose full randomization.
Systems with ancient and/or broken binaries should be configured
with CONFIG_COMPAT_BRK enabled, which excludes the heap from process
address space randomization.
To change the value permanently, add the setting to /etc/sysctl.conf.
Note that ASLR can slow program execution slightly and put some additional pressure on memory caches. When debugging code, and especially when trying to track down memory access bugs, ASLR is an impediment because it makes bugs non deterministic. By turning ASLR off, you can typically more easily reliably reproduce the bug.
You can disable ASLR for a specific program and its child processes by using the following command:
$ setarch `uname -m` -R program [args ...]
Wny build with ASLR enabled if a user can simply bypass it? I have to wonder if setarch should be one of the utilities that should be removed if hardening a Linux system.
Finally, ASLR is just one of a number of techniques that can be used to thwart an attacker. Other useful techniques include stack canaries, NX and W^R (non-executable stack) and RELRO (RELocation Read-Only).
