ASLR was a security game changer. Could expanding the concept be one, too?

By September 26, 2017 June 27th, 2019 Blog, Technical

As long as there has been a commercial internet, cybersecurity has largely been predicated on the concept of guess work, better known as Heuristics. Looking for patterns or matching words and phrases that were close enough to known or variations of known vulnerabilities/attacks have been the norm. These solutions are, by definition, trial and error.

But with a seemingly never-ending increase in vulnerabilities, hackers and attacks, the cyber security status quo is simply not sufficient to provide the level of certainty needed to instill confidence and improve reliability in an app driven, interconnected world. We need higher accuracy, less complexity and more simplicity as more devices, applications and individuals join the internet.

The inspiration for one powerful new solution can be found in the past – in a seemingly unrelated technology.

Attacking the OS to get to an app

Back in 2001, hackers were still largely amateurs who created malware or penetrated systems for fun or academic credibility. The first DoS attacks occurred that year and so did a new approach to OS security: Address Space Layout Randomization or ASLR.

ASLR is now a standard component of most mainstream operating systems, from MS Windows and Apple OS to Android and even Nintendo 3DS. Before ASLR was adopted, OS address locations were well known or easy to predict by hackers looking for an avenue of attack.

The approach of the PaX Project to block these attacks was deceptively simple: randomize the address of OS processes. If a malicious attacker entered a wrong address location, the target application would crash, the exploit would be halted and a sys admin might be alerted.

Now comes Name Space Layout Randomization – NSLR

Name Space Layout Randomization or NSLR is the equivalent of ASLR for Java-based web applications. To be successful, a malicious attacker who wants to introduce a Code Injection exploit in Java needs to know the exact names of classes and packages to be invoked. Making the Java class packages non-deterministic, or randomized, defeats any code injection exploit.

Name Space Layout Randomization NSLRFor example, with NSLR enabled, the java.lang.System class will be randomized and renamed to something like java$85rbuLjHNERijUhN.lang.System. Any exploit that tries to invoke java.lang.System will automatically fail. For attackers to successfully execute an attack they would need to know the randomized package name which changes each time the JVM boots.

Attempts to brute force the system and retrieve the randomized package name is not feasible, either. Waratek’s standard configuration includes NSLR with a minimum level of security at 96-bit names, which would require several thousand years to crack the encryption. Namespaces can be randomized up to up to 1024 bits.

A code injection attack attempted in an NSLR­ enabled JVM will generate a ClassNotFoundException, ending the attack.

NSLR is the kind of emerging security solution that could be the replacement for heuristics we’ve all be waiting to arrive.

 

John Matthew Holt

Author John Matthew Holt

John Matthew Holt is CTO and Founder of Waratek. He is the inventive inspiration and technical driving force behind Waratek’s groundbreaking research and development into distributed computing and virtualization technologies, which has led to the granting of over 50 patents to date with many more pending.

More posts by John Matthew Holt
X