Bypassing Windows ASLR by determining the library address using shared pages

Question

I am quite familiar with ASLR, but today I heard a new interesting fact about the implementation of ASLR in Windows.

In order to optimize performance if process A and B load the same dll Windows will only load it once to physical memory and both processes will share the same instance via shared pages.

This is old news .. But the interesting part is that both process A and B will load the shared library in the same virtual address (why ??).

It seems to me that any local attack (e.g. privilege escalation) can easily bypass ASLR by the following way:

1. Create a new dummy process
2. Check the address of dlls of interest (kernel32, user32 ..)
3. Attack the privileged process and bypass ASLR with the information from step 2.

I have done some simple tests using Olly and found that shared libraries are indeed loaded in the same virtual address.

If this is really the case, is ASLR useless for local exploitation ?

Answer 1

You are correct, ASLR is little defense against a local attacker. It is primarily designed to thwart hard-coded addresses in remote exploits.

Edit: Some details in my previous answer were incorrect, though the point above still stands. An ASLR-enabled DLL's base address is actually a function of both: (1) a random offset chosen by Windows from a set of 256 possible values at boot time; and (2) the order in which the DLL is loaded, which for known DLLs is randomized by the Session Manager during system startup. Knowing just the random offset is therefore not sufficient to compute the base address of an arbitrary ASLR'd DLL. However, if you are able to directly observe the address of a target DLL in shared memory, as you describe, then all bets are off anyway.

Sources: http://www.symantec.com/avcenter/reference/Address_Space_Layout_Randomization.pdf Windows Internals, 6th Edition