Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

ASLR Was a Security Game Changer. Could NSLR Be?

DZone's Guide to

ASLR Was a Security Game Changer. Could NSLR Be?

What if there was a way to encrypt a file so that it would take a computer thousands of years to decrypt it? NSLR may just be the answer.

· Security Zone
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

As long as there has been a commercial internet, cybersecurity has largely been predicated on the concept of guesswork, 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 cybersecurity 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 sysadmin 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.

For 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 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.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,nslr ,cybersecurity ,encryption

Published at DZone with permission of John Matthew Holt, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}