Re: ASLR: Address Space Layout Randomization

[Alexander Sotirov <asotirov () determina com>]

I am amazed by the misconceptions about ASLR on this list. Here's what it really
does:

One common technique for exploiting vulnerabilities on Windows is to use a piece
of existing code as a trampoline to jump into the shellcode. Let's take a simple
stack overflow as an example.

int foo(char* input)
{
    char buf[256];
    strcpy(buf, input);
}

We will pass an input string longer than 256 bytes and overwrite the return
address. The problem is deciding what value to put in the return address. We can
put our shellcode in the buf[] variable, but we don't know its address. Since
most programs on Windows are multi-threaded and each thread has its own stack,
the location of the stack is not easy to predict.

Let's assume that the code of the function leaves the address of our input
string in the edi register. Then we can overwrite the return address with
0x75021421, which is the address of a "jmp edi" instruction in WS2_HELP.DLL.
This DLL is always loaded at the same address, and has not changed between
Windows 2000 SP0 and SP4.

When the vulnerable function returns, it will return to the "jmp edi"
instruction, which will jump to our shellcode.

This technique is widely used. On DEP enabled machines you have to use the
return-into-libc technique, which is just a more complication variation on the
same theme.

ALSR will make sure that the address where WS2_HELP.DLL is loaded is different
on every machine, which will make your exploit fail in 254 out of 255 tries.
When the exploit tries to jump to 0x75021421, it will most likely hit invalid
memory and the application will crash. Crashing is definitely preferable than
remote code execution.

One thing to keep in mind is that all this is happening before the attacker gets
a chance to execute any shellcode. This means that you cannot bruteforce your
the address of the DLL by trying all 256 addresses in a millisecond. Each
attempt will require sending the exploit again. In the case of a network server,
the first attempt will crash the application and you don't get any more tries.
If you are exploiting a buffer overflow in Internet Explorer, the user will
notice that a certain webpage crashes their browser and will not go there again.

In some circumstances (if the server handles exceptions, or restarts after a
crash) it is possible to bypass ASLR by bruteforcing it, but this is not very
common.

Here's a good description of ASLR's weaknesses: http://www.wehnus.com/technology.pl


Alex
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.