Address Space Layout Randomization (ALSR) – It’s good, but it’s not good enough

By Archis Gore

It’s a shocking statistic: 80% of successful cyberattacks rely on exploiting memory corruption vulnerabilities. This category of attack includes buffer overflows, stack smashing, and return-oriented programming (ROP) assaults. These are all different approaches aimed at corrupting areas of allocated application memory by forcing the hacker’s data or code to be written into unexpected areas of memory outside the designed scope of the program.

The bad news is that if you’re hit by one of these attacks, it could crash the application, but it could also give a malicious hacker full control of your system. They can then steal data or inject and run their own code while you are totally unaware of the breach. The good news is that, over time, various countermeasures have been developed that can be used as the first line of defense.

ASLR to the rescue?

Address Space Layout Randomization (ASLR) is a prime example of these techniques. It works by mixing up where the essential elements of a program are placed in the memory layout.  This is achieved by randomly assigning an offset for all the key base memory address positions for executables, stack, heap, and shared libraries. Because this randomized offset is initially unknown to any potential hackers, it makes it harder to mount an attack. They have to work out the offset value before they can even get started.

FreeBSD was the first mainstream OS to support ASLR in 2003, followed by Linux in 2005, and Windows in 2007. Today, virtually any major OS you choose will have a mature ASLR implementation built-in and ready to use. Best of all, there’s no additional charge.

So far so good. If that were the end of the story, we’d all be secure and sleep well at night.

Unfortunately, it’s not. ASLR has been around for almost 20 years now. That’s plenty of time for hackers to have worked their way around it. Breaking or circumventing ASLR is simply the first thing on every hacker’s to-do list when crafting a modern memory corruption attack.

Here are just a few of the main ASLR weaknesses:

  1. The memory offset assigned by ASLR remains the same until the system is rebooted or processes are restarted. This means there is usually plenty of time for a bad actor to figure it out. And once the magic number is discovered, it works for everything. That’s because all the libraries and functions share the same offset from the standard memory addresses.
  2. If any program or process is set to restart automatically after a crash, it could easily become the target of a brute force attack where numerous trial and error attempts to guess the offset can be made.
  3. Some hardware features designed to enhance performance can also be manipulated to sidestep ASLR. An example, the Branch Target Buffer (BTB) built into CPUs can be exploited to induce side-channel memory leaks. BTBs are intended to improve predictive execution functionality but have been demonstrated to reveal an ALSR offset in about 60 milliseconds.
  4. In one of my previous blogs, I showed how ROP chains and gadgets can also easily be leveraged to expose an ASLR offset.

How to improve on ASLR protection

My view is that ALSR is a useful first line of defense against memory corruption attacks, especially if you have nothing better. But it’s not perfect, and in a modern setting it’s no longer good enough.

That’s why we designed Polymorphing technology to take your cybersecurity protection to an exponentially higher level, all without any impact on performance or functionality.

It works by running the source code through an advanced polymorphic compiler to randomize the low-level machine code for the entire operating system. This means all the addresses inside every executable, library, and function are unique; instruction sets for all libraries or executables are scrambled; you are provided with an entire one-of-a-kind resource mapping. Even better, your entire Linux environment can be re-scrambled every 24 hours.

The bottom line? Polymorphing for Linux is the ultimate way to improve on ASLR and to make memory corruption vulnerabilities a thing of the past.

If you’d like some more in-depth information, take a look at the technical white paper here.

Interested in learning more?

Be the first to hear about the latest product releases and cybersecurity news.

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive licensee of Linus Torvalds, owner of the mark on a world­wide basis.