1

I have a question about ASLR which allocates randomized addresses for things. Based on my understanding (which might be wrong), a modern OS has pretty complicated memory management mechanisms and it seems REALLY challenging to allocate the same address for the same program every single time. In other words, by intuition, I feel like randomized address should be the default behavior, and to allocate static address would require some effort.

Is this understanding completely wrong? Or the OS allocates separate address space for each process so that in each address space the process always gets its comfortable static address by default?

  • 1
    ASLR comes in many forms. Are you talking about library base randomization? Process base randomization? Randomization of heap allocations (mmap), or what? Also note that non-ASLR doesn't imply "allocating the same address every single time". A lack of ASLR just means that the addresses will be predictable. – forest Dec 14 '18 at 3:30
  • @forest, just curious, if without ASLR and the libraries are not allocated at the same address every single time, then how could one predict their addresses? Do you mean trying a few possible addresses or there is some other way to find out? – ios learner Dec 14 '18 at 9:27
  • 1
    You may want to look into the details of how position-independent code works, specifically how GOT and PLT works to make code position-independent. The details are too complex for a single comment. See stackoverflow.com/q/813980, stackoverflow.com/q/5130654, and eli.thegreenplace.net/2011/11/03/…. – forest Dec 14 '18 at 9:29
2

Most modern systems have a Memory Management Unit, or MMU. The MMU is responsible for translating physical addresses to virtual addresses. This is used to give each process its own private virtual memory. One process' address X is not the same as another process' address X. This improves performance, security, and reduces the risk of crashes, but it also has the benefit of being usable to implement ASLR. While data may be placed in non-random addresses in physical memory, the system is free to place the data anywhere it wants in a process' virtual memory.

When a process is first created, the only real memory it has access to is the stack, which is limited and is not meant to be used for general purposes. Whenever a non-trivial amount of memory is required, the process needs to use the heap. The only way to do this is to request memory from the kernel via a system call. This system call is given a few arguments specifying the amount of memory it wants, the type of memory, etc. The call returns the base address of some freshly allocated memory of the size specified. One of the things ASLR does is cause this base address to be unpredictable. When ASLR is disabled, allocated memory is placed in predictable locations.

ASLR does more than just randomize the base of allocated memory. When a binary is executed, the dynamic linker connects it to all the shared libraries it needs. Although any given library is kept in only one place in physical memory, the system is able to translate it to a virtual address for each process that uses it. This address translation is done for efficiency reasons, but ASLR makes additional use of it by ensuring the virtual address is random. An executable specially compiled as a Position-Independent Executable (PIE) can call library functions even though the library's base address is randomized.

This is not all ASLR does, and certain security-focused operating systems (OpenBSD, HardenedBSD, Linux with grsecurity/PaX patches, etc.) use a form of ASLR that does even more.

  • Hi, thanks for your answer. I find this and the other "how ASLR/DEP work" post very helpful. It makes sense to me now that ALSR is mostly to guard against ROP (instead of against a "simple" overflow where the jump can be done by offset and is irrelevant to the base address of the stack?) – ios learner Dec 14 '18 at 9:25
  • @ioslearner ASLR guards against a lot of things, not just ROP. Not that ASLR isn't hard to bypass... – forest Dec 14 '18 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.