The Evolving Arms Race of IT Security Countermeasures
Dutch security research team VUSec released information on a new attack technique this week 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. While we are still confirming the impact of this new technique, it 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 taken closer looks 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 intention 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 behavior in programs and, last but not least, using a crash to completely rewrite the code of an application.
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 popularized the idea that certain kinds of 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 realized that while most memory locations can be randomized, 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 defense 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 without a doubt lead to another defense 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 lies in the realm of researches, it is important for every organization to understand that there is no final word in security.
Any safeguard that exists will eventually be circumvented and every attack will be countered in one way or another. To maintain security standards means to constantly update and improve infrastructure, training and policy.
If someone is offering 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.