The Evolving Arms Race of IT Security Countermeasures

The attack technique appears to circumvent so-called ASLR protection mechanisms by triaging the exact memory location of a running process from differences in function response times.

First Published 16th February 2017  |  Latest Refresh 3rd March 2023

The Evolving Arms Race of IT Security Countermeasures

Ask yourself - who really benefits from the arms race?

4 min read  |  Reflare Research Team

Dutch security research team VUSec released information on an attack technique which appears capable of circumventing so-called ASLR protection mechanisms by triaging the exact memory location of a running process from differences in function response times. This makes for a good example to explore the constant arms race between offensive and defensive technologies.

Defining hack and countermeasures

The term hack has countless definitions, and many of our previous briefings have looked closely at some of them. For the purposes of this briefing, a hack will be anything allowing the attacker to do things with a system that the systems designer did not intend them to do.

There are many ways to do unintended things on a system. Probably the best-known approach is to steal or guess passwords for users with more permissions and abuse them. Other approaches include installing malware, calling undocumented APIs, triggering unintended behaviour in programs, and last but not least, using a crash to rewrite the code of an application completely.

The last class of vulnerabilities - so-called memory corruption vulnerabilities - are extremely common in binary software. The battle to prevent attackers from abusing them has likewise been going on for a long time and makes for a good example of how attacks and countermeasures evolve.

A brief history of memory corruption in common terms

In 1996, a hacker by the handle Aleph One popularised the idea that certain programming mistakes could be abused to trick the vulnerable application into running arbitrary code. His attacks depended on two things: Knowing where exactly in memory the application was located and being able to run data as code.

As the technique became more widely abused, two countermeasures were developed.

The first approach was to change the memory location of an application each time it was started so attackers wouldn’t be able to guess it (ASLR). Attackers quickly realised that while most memory locations can be randomised, those of some critical features can not. Also in applications that restarted automatically, the correct address could simply be guessed with enough tries. Thus new attacks such as Return-To-Library and NOP-Sledding were deployed.

Another approach was to make sure that data and code were strictly separated and that data could thus not be executed (NX). This requires hardware and software support and breaks some legacy applications. At the same time, some of the techniques developed to combat ASLR were able to circumvent NX as well.

The next step for the defence was the use of so-called Canary values to detect if an attack had occurred. Attackers countered by either guessing the Canary value through data leaks or circumventing the mechanism altogether (SEH).

The introduction of 64-bit processors made guessing attacks virtually impossible and thus significantly strengthened ASLR and Canary protection mechanisms. Newer CPU generations introduced more and more sophisticated NX mechanisms at the same time. Attacks circumventing the need to provide code in the first place (ROP) were developed to counter them.

The new attack mentioned at the beginning of this briefing is yet another technique to counter current generation ASLR protections. If it finds widespread adaptation, it will undoubtedly lead to another defence mechanism being deployed against it.

The cycle of offensive and defensive technologies continues.


IT security is an ongoing and never-ending arms race between attacks and preventive measures. While the technical details of these measures lie in the realm of research, it is essential for every organisation to understand that there is no final word in security.

Any existing safeguard will eventually be circumvented, and every attack will be countered in one way or another. Maintaining security standards means constantly updating and improving infrastructure, training, and policy.

If someone offers you a “one-shot solution” that will “make your network secure for good”, you can always safely conclude that you are dealing with snake oil.

Subscribe by email