What is ASLR?
ASLR, address space layout randomization, is an operating-system defense that makes memory-corruption attacks such as buffer overflows harder to turn into working exploits. When a program loads, the system places its code, libraries, stack and heap at randomized addresses instead of fixed, predictable ones. It does not fix the underlying bug; it removes the certainty an attacker needs to use that bug reliably.
Why randomization breaks exploits
To hijack a program through a memory bug, an attacker usually has to know where things sit in memory, for example the address of a function to jump to or a buffer to land code in. With fixed addresses, those values are the same on every run and can be hardcoded into an exploit. ASLR shuffles the layout at load time, so a hardcoded address is almost always wrong. The usual result is that the program crashes instead of being taken over, which converts a quiet compromise into a visible failure.
Where it fits with other protections
ASLR is one of three memory protections a candidate should know together. Data Execution Prevention marks data regions as non-executable so injected code will not run; stack canaries place a secret value before a return address to detect an overflow before the function returns; and ASLR hides where everything is. They complement each other, and strong systems enable all three plus keep software patched.
Its limits
ASLR is not absolute. An information-disclosure bug that leaks a real address can defeat it, because once the attacker learns where one thing lives they can calculate the rest. Low randomization entropy on older or 32-bit systems makes guessing feasible, and techniques that reuse existing code can sidestep related defenses. That is why ASLR is layered with the other protections and treated as a cost-raiser, not a cure; the real fix is still to eliminate the memory bug, ideally by writing the code in a memory-safe language.
ASLR on the CompTIA Security+ exam
In SY0-801, ASLR is part of the exploit-protection material: it is taught among the defenses against buffer overflows under objective 2.5, and among the protections to keep turned on against operating system vulnerabilities under objective 2.4. When a scenario asks how to make memory-corruption bugs harder to exploit, the scoring answers are a memory-safe language plus platform protections such as DEP/NX, ASLR and stack canaries, with patching. Network and password controls do not address memory corruption.