5

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 ?

Michael
  • 796
  • 11
  • 27
  • 2
    If the DLL would be loaded at a different address then it has to be relocated and the RAM pages can no longer be shared. Major point of ASLR is that where it is loaded on your machine isn't the same as where it is loaded on mine. And when you reboot it will be different as well. – Hans Passant Apr 25 '15 at 14:26
  • As far as I remember .. Each process has a table that translates addresses of Virtual Pages to Physical Pages. Each process has a unique table of its own. Couldn't Microsoft load the DLL one time into Physical ram and for each process load the DLL in a different Virtual Address ? – Michael Apr 25 '15 at 15:29
  • 2
    No, relocation changes the code so that one copy is no longer valid. – Hans Passant Apr 25 '15 at 15:39

1 Answers1

5

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

peterdn
  • 2,386
  • 1
  • 23
  • 24
  • 1
    Very Interesting .. Is this "technique" used in the wild ? I'v read some case studies about local exploits and never saw an attacker using this technique .. – Michael Apr 25 '15 at 15:30
  • 1
    @MichaelEngstler apologies, I believe I was completely wrong on that detail. I've amended my answer to reflect. – peterdn Apr 25 '15 at 18:50