I want to evaluate whether it's worth it to add ASLR to a proprietary operating system. This OS runs multiple applications that don't trust each other and exchanges data over the network, so the threats that ASLR mitigates do apply. Given infinite resources, I would add ALSR.

But resources are finite. Maybe we'd get a stronger security by spending time on other pursuits such as more intensive testing, finer static analysis, general design improvements, etc.

We can look at our OS and evaluate the cost of ASLR (initial design, avoiding address leaks through e.g. timing, greater difficulty of debugging, …). How can we evaluate the benefits?

ASLR doesn't prevent vulnerabilities, it only makes exploits more difficult. I tend to think that the least exploitable vulnerability is the one that doesn't exist and attackers will always find a way, but this is just a feeling, I don't have data. Is it common for ASLR to make exploitation impossible? How can we quantify the benefits of ASLR?

  • applications that don't trust each other -> ALSR will not give any protection from someone inside the OS. For example, on linux, you could simply read /proc/<PID>/maps and your stack randomization becomes useless because it it printed there. And /proc/<PID>/maps is mode 444.
    – grochmal
    Sep 29, 2016 at 23:09

3 Answers 3


One way to get some data on this is to weigh the success/fail rate of ASLR for this particular OS by implementing it in a testing environment, and then running attacks against the non-ASLR version, and the ASLR version. Of course, this would be very one sided being that it is only being tested by a specific entity instead of a community. However, you will achieve a rough idea of how effective ASLR is, how accurate that number is depends on how sophisticated the attacks are.

Not one protection measure will succeed in blocking all attacks. Given time, resources, and persistence, an attacker will eventually succeed. ASLR sets the bar higher for the skills needed to fully take over an OS, but it doesn't make it impossible.

Consider Defense in Depth as an arguing point for ASLR, solid security designs utilize multiple defenses before an external user actually reaches an application. It's there to protect the OS if someone was smart enough to get around the inner defenses. What if the individual is just a script kitty who got lucky with getting into the network, but has no idea how ASLR works? Attack thwarted, or at the least greatly reduced its impact. What if the attacker were a professional? Utilizing ASLR certainly doesn't make their objective easier for them, they might keep persisting or just tire out and take what they can get.

Of course, since this OS is proprietary, it certainly wouldn't look good on the developer(s) if someone were to compromise it, then have it be revealed that no protection measure was ever implemented at the core of the OS. This is almost like a bank using residential locks on a money vault.

  • How can I measure the effectiveness of ASLR by running attacks? Should I add deliberate vulnerabilities and then make assumptions about how someone would attack them? But how would I pick these assumptions? Sep 30, 2016 at 8:01
  • “it certainly wouldn't look good on the developer(s) if someone were to compromise it” So is ASLR a marketing thing rather than an effective security tool? My question is about evaluating it as an effective security tool. Sep 30, 2016 at 8:01
  • It'd probably become a marketing point if the OS got exploited due to the lack of a ASLR, but otherwise no one will raise an eyebrow unless they use the OS for technical operations and care for security. Although, SELinux does advertise itself as being the most secure kernel security module. Adding vulnerabilities and executing them regularly (for modern threats) against the OS would show how ASLR would make these vulnerabilities less likely to occur, but the threat of a 0-Day is a factor to consider with or without ASLR. Having an external entity do the appsec testing may be best for this.
    – LampShade
    Sep 30, 2016 at 13:59

Test the apps you have running on this custom OS for input vulnerabilities, especially buffer overruns and stack overflows. If you find any, it's a sign that defense in depth is a more necessary strategy than you realized.

You don't have to build any shellcode or carry the attacks through to completion. It just has to be enough to convince the other engineers that you can inject arbitrary values into the instruction pointer. That's when the benefits of ASLR actually kick in.


ASLR is a known good method of making certain exploits difficult. If you want to achieve a similar functionality then researching alternatives would be an expensive task. You already know that ASLR is good, while your research outcome is not a guaranteed solution. That doesn't sound very exciting to me. You can refer to this Microsoft security article as to when ASLR shows it's value: https://blogs.technet.microsoft.com/srd/2014/03/12/when-aslr-makes-the-difference/.

The cost benefits of ASLR also depends on the level of control that you have on which applications run on your OS.

  • Can you control the quality of applications running on your OS? If yes, then focusing on testing, static analysis etc would matter. Otherwise, it doesn't really give you a lot of added benefits.
  • ASLR is useful for a very specific set of vulnerabilities. An attacker is likely focus on these only if the machine running your OS is a very critical system. For non critical systems, you can focus on finding alternative solutions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .