Hack This? Making Software a Moving Target

It sometimes seems that the black hats are always one step ahead of the white hats in the never-ending security game. One of the especially invidious ways hackers have found to evade detection is through mutation – changing the code in a virus on each copy, defeating classical signature detection methods and potentially requiring new signatures to be built and redistributed for each mutation.

The seriousness of this problem may be compounded by the growing lack of diversity in systems in the IoT at large – in industrial, home, medical and many other applications. ARM through its many customers has made this revolution possible but at the same time present to the hacking world an attractive and focused target of incredibly high value. Find a way to hack into the core of one system and you can potentially attack many systems with the same exploit. I’m sure ARM is very careful in analyzing and removing as many bugs as possible in their core software, but software by its nature is never perfect. Bugs will be found, especially since hackers can experiment at their leisure with their own ARM-based systems.

But there’s way to turn the tables on hackers by reintroducing diversity into systems, in fact even into a single system, so that exploits are always trying to aim at moving targets. The method started with a technique called address-space layout randomization (ASLR) introduced early in the millennium. In conventional computing the memory map of a program has fairly predictable structure. The stack starts in a certain well defined place, as does the heap. The easy “discoverability” of the stack is what enables so many basic hacks; you can easily change return routine return locations through tricks like buffer overflows. Less well-known but equally damaging exploits are known for attacking the heap or even the code.

ASLR in its early incarnation aimed to defeat hacks by randomizing the address map on program startup. In principle it would be much harder for exploits to discover key information because they wouldn’t know where to look. Sadly, as is eventually the case for all defenses, hackers found a way around ASLR by exploiting “memory disclosure bugs”, cases where applications may at least temporarily reveal information from which address map offsets can be reconstructed or code snippets can be extracted or overwritten.

Problems associated with this class of attack are very real. The Linux kernel has known memory discovery vulnerabilities. Some suggested fixes have included execute-only memory where it is not possible to overwrite code, but this becomes very challenging in the presence of Just-In-Time (JIT) programming where code and data can easily intermingle. Since JIT is becoming increasingly common – in Java and in Javascript (used by most browsers) – potential attacks have already been exposed.

But if viruses can constantly mutate, why not the address map also? A team at Columbia have created just such a defense which they call Shuffler. Shuffler randomizes code locations every tens of milliseconds (including for itself), effectively creating a deadline for an attacker – if they can’t figure out and exploit a disclosure in that time, their exploit will fail. Shuffler is software-based and uses various techniques to minimize performance impact but still shows up to a ~15% overhead. You could easily imagine hardware assist removing most of this overhead (but this would also need to be secured).

Another interesting approach to handling code read attacks on JIT code uses a technique called destructive code read. Code can be executed normally but if it is read it is immediately garbled, as a method to undermine the usefulness of memory disclosure. The software based on this approach is called Heisenbyte in tribute to the Heisenberg principle which asserts that observation of a state must change the state.

You can read a lightweight write-up on Shuffler HERE and a more detailed paper HERE. A description of a memory disclosure vulnerability in Adobe Shockwave is HERE and a paper on Heisenbyte can be found HERE.

More articles by Bernard…