The minimalist vulnerable example could be this
vuln.c:
#include <stdio.h> #include <unistd.h> int main( int argc, char *argv[] ) { char buf[4]; printf("%#p\n", &buf); strcpy( buf, argv[1] ); return 0; }Because of the Address Space Layout Randomization (ASLR), this bug is tough to exploit: if the binary is compiled with the right options and the kernel is configured to fully randomize the address space, it becomes impossible to guess where the buffer is, nor the location of the functions' libraries.
But there was a trick (firstly published by Jon Erickson in his book): the randomization is computed at
exec*() time, the seed used to
generate the entropy was rekeyed every X milliseconds with the PID
and the jiffies variable (which is the number of clock
interruptions since the boot), it was known to be cryptographically
weak but it was good enough for daemons: remotely, it's not possible
to guess either the PID or jiffies (except in case of a format
string vulnerability or an information leak).
But locally, the entropy was just useless: a minimalistic process which would just
exec*() another one would get the same memory
layout because both program has the same PID and the jiffies would
not be updated.
Practically, even on a fully randomized system, it was possible to guess the addresses, here is the minimalistic program just printing the address of its buffer and executing the vulnerable binary (which itself prints its buffer address):
#include <unistd.h> int main(int argc, char **argv) { char dummy[4] = "AAA"; printf("%#p\n", dummy); execl("./vuln", dummy, NULL); }The following Python code based on
expect runs the exploit
multiple times and compute the differences between the addresses of
./vuln and ./exploit :
#! /usr/bin/python import pexpect while True: child = pexpect.spawn('./exploit') child.sendeof() a=int(child.readline()[:-2], 16) b=int(child.readline()[:-2], 16) print 'offset=%#x' % (b-a) child.expect(pexpect.EOF)Let's do it:
lenny32:/tmp$ uname -a Linux lenny32 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686 GNU/Linux lenny32:/tmp$ cat /proc/sys/kernel/randomize_va_space 2 lenny32:/tmp$ ./guess_offset offset=0x10 offset=0x148160 offset=0x10 offset=0x10 offset=0x10 offset=0x1bf9d0 offset=0x10 offset=0x1d91f0 offset=0x10 offset=-0x2ba2a0 offset=0x3d050 offset=0x10 offset=0x10 offset=0x10 offset=-0x19a990 offset=0x10 offset=0x10 offset=0x10 offset=0x10 offset=0x10 offset=0x10 offset=0x10 KeyboardInterruptMost of the time, we can see that the offset is equals to
0x10,
great! But on a 2.6.32 kernel, the result is totally different:
$ ./guess_offset offset=0x4fddb0 offset=0x69f330 offset=0x137e40 offset=0x6b49f0 offset=0x407600 offset=0x14cf50 offset=0x3f4930 offset=0x4d0f80 offset=0x107d20 offset=0x1969b0 offset=0x1ae360 offset=0x409b30In other words, it's now impossible to guess the address space layout with this method.
When was patched the function in charge of the randomness,
get_random_int()? Let's use git-blame in order to annotate each
source line with its modification date and commit:
% git blame -L 1688,1709 drivers/char/random.c 8a0a9bd4 DEFINE_PER_CPU(__u32 [4], get_random_int_hash); ^1da177e unsigned int get_random_int(void) ^1da177e { 8a0a9bd4 struct keydata *keyptr; 8a0a9bd4 __u32 *hash = get_cpu_var(get_random_int_hash); 8a0a9bd4 int ret; 8a0a9bd4 8a0a9bd4 keyptr = get_keyptr(); 26a9a418 hash[0] += current->pid + jiffies + get_cycles(); 8a0a9bd4 8a0a9bd4 ret = half_md4_transform(hash, keyptr->secret); 8a0a9bd4 put_cpu_var(get_random_int_hash); 8a0a9bd4 8a0a9bd4 return ret; ^1da177e } ^1da177e
Arg! It was patched in commit 8a0a9bd4 by Linus Torvalds in
response to CVE2009-3238 in May 2009. The first released kernel
carrying this patch is the 2.6.30 in June 2009.
Actually, I'm not aware of any generic trick to achieve the same goal (now that information leaks on /proc entries have been fixed too).
