Bypass Windows ASLR by defining library address using shared pages

Question

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

To optimize performance, if process A and B load the same DLL, Windows will load only once in physical memory, and both processes will share the same instance through shared pages.

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

It seems to me that any local attack (for example, privilege escalation) can easily bypass ASLR as follows:

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 did some simple tests with Olly and found that shared libraries actually loaded into the same virtual address.

If so, is ASLR useless for local use?

Answer 1

You are right, ASLR provides little protection against a local attacker. It is primarily designed to prevent hard coded addresses in remote exploits.

Edit: Some of the details in my previous answer were incorrect, although the above point is still worth it. The base address of the ASLR-enabled DLL is actually a function of both: (1) a random offset selected by Windows from a set of 256 possible values ​​at boot time; and (2) the loading order of the DLL, which for known DLLs is randomized by the session manager during system startup. Knowing just random bias is therefore not enough to calculate the base address of an arbitrary ASLR'd library. However, if you can directly observe the address of the target DLL in shared memory, as you described, all the bets are all the same.

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