This document discusses popular approaches to preventing code injection attacks and argues they are inadequate. It introduces Tainted Lexical Analysis, Name-Space Layout Randomization, Component Privilege De-escalation, and Runtime Protection Rules as new techniques that can prevent code injection attacks without heuristics and provide always-on protection, virtual patching capabilities, and prevention of serialization vulnerabilities and API abuse. These techniques are presented as superior alternatives to traditional application security approaches.

1. Popular Approaches to Preventing
Code Injection Attacks are
Dangerously Wrong
John Matthew Holt
CTO and Founder, Waratek

2. About John Matthew Holt
I’m John Matthew Holt
I’m the founder and CTO of Waratek.
I am a JVM/JIT compiler engineer by study
and training, and I hold more than 60 patents
for inventions that span abstract machine,
dynamic recompilation, distributed
computing and virtualization technologies.
My company, Waratek, offers a unique,
virtualization based approach to Application
Security.
2

3. Attendee Takeaways
1. Review recent advances in runtime protection in
the application security space
2. Understanding of the most frequently employed
un-validated bytecode attacks in the JVM, where
they occur and forms of mitigation
3. Working knowledge of the new, state-of-the-art
application security technique neutralizing code
injection attacks
3

4. Part I. The Problems facing AppSec Teams
are well known
4

5. “Better coding will cure
application attacks.”
5

6. o Oracle finds a new Java flaw <100
hours
o 96% of apps use open source
software;
o 67% of those include flaws known
for an average of 1,527 days;
o 2 billion flawed components
downloaded in 2016
5
Humans cannot keep pace with
old school find and fix approach
Sources: Oracle; Black Duck; Veracode; Apache Foundation
6

7. 5
“We have all the security
tools we need.”
7

8. Traditional cybersecurity
approaches do not work
against modern attacks
Sources: Ponemon Institute; Gartner; IDC
IT Professionals tell researchers:
o The frequency and severity of attacks at
the application layer is greater than at
the network layer.
o Lack of visibility in the application layer is
the main barrier to achieving a strong
application security posture.
o WAFs, which sit outside the runtime, are
the primary App Sec defense.
80 percent of today’s top
firewalls miss attacks –
NSS Labs 2017 Next Gen Firewall
Tests
8

9. Heuristics are good.
9

10. Heuristics are bad for AppSec
Heuristics cause all of the ‘false positives’ for which WAFs / SASTs /
DASTs are infamous
10

11. Facts, Not Opinions
1. We can’t rely on developers to write
secure code
2. Your developers are only responsible
for < 20% of the code you actually run
3. Patching and updating everything is
wholly unrealistic
11

12. Part II. Non-Heuristic Application
Security in the Runtime opens the
door to unique and improved
application protection
12

13. Tainted Lexical Analysis (TLA)
solves SQL injection, stored-XSS, reflected-
XSS, path/directory traversal, XPath injection,
OS command injection, and reflection
injection vulnerabilities

14. o Real time memory-tracing marks as “untrusted” all
user-input data to an app
o When “untrusted” user-input data is passed to a
structured grammar, tainted lexical analysis accurately
and reliably detects code-injection attacks - without:
o Code changes
o Pattern matching, regex, whitelists or blacklists, or
signatures
o Tuning or profiling
TLA Solves Code-Injection Vulnerabilities

15. Name-Space Layout
Randomization (NSLR)
solves unvalidated bytecode
attacks and Attach-API attacks

16. NSLR = ‘ASLR’ for the JVM
Name-Space Layout Randomization (NSLR):
o Stops unvalidated bytecode attacks including
Attach-API attacks
o No rules required; always-on
o No performance overhead
o Never been done for Java before
o Equivalent of ASLR inside the JVM
o Every mainstream OS includes ASLR today
o ASLR is 10 years old but Java and .NET haven’t caught
up until now
16

17. Name-Space Layout Randomization
(NSLR)
• Hardens the JVM by randomizing the java.*
namespace
• Making the Java class packages non-deterministic
makes it impossible to execute unvalidated bytecode
• Completely transparent to the application
• NSLR randomization example:
java.lang.System
will be randomized to:
java$4yE0PCU8UPMcnfaI.lang.System
17

18. NSLR is ‘Always-On’
96-bits randomized, up to 1024 bits
18

19. NSLR solves Attach-API attacks
19

20. Component Privilege De-escalation
solves software composition
vulnerabilities, API abuse,
deserialization vulnerabilities,
and zero-days

21. Component Privilege De-Escalation
• Component Privilege De-Escalation acts where application code ends and
component code begins
• When application code invokes a method in a ‘de-escalated component’ the
calling thread’s privileges are reduced for the duration of the component call
21

22. Privilege De-Escalation solves
Deserial Vulns
22
o Deserialization attacks work by abusing the deserialization APIs
to perform non-intended operations such as process forking,
class loading, etc.
o De-escalating components guarantees that the component APIs
cannot be used to perform such operations

23. Privilege De-Escalation solves
Deserial Vulns
o No source-code changes
o No blacklists, no whitelists, no config, no tuning
o No false positives
o No performance overhead
o Zero-day and ‘won’t fix’ protection
This approach would have prevented the
Equifax attack and any similar Remote Code
Execution attack based on Struts 2 CVE-
2017-5638 and the recent CVE-2017-9805
23

24. Rule Language
solves live virtual patching

25. Runtime Protection Rules
o Unbounced rules replace/insert
functionality at runtime to provide
“patch-equivalent” remediation
o Rules make it possible to virtually patch
any vulnerability in Java CPUs,
AppServers (WebLogic, JBoss, Tomcat,
etc) and frameworks
o Virtual patching applies instantly at
runtime with immediate effect, without
restarting the target application 25

26. CVE-2016-3092
26

27. Source Code Fix for CVE-2016-3092
The vulnerability was a missing bounds check in the <init> method of
class:
org.apache.tomcat.util.http.fileupload.MultipartS
tream
The source-code fix is the addition of the line:
this.bufSize = Math.max(bufSize,
boundaryLength*2);
which adds a bounds check to the bufSize value
27

28. Virtual Patch for CVE-2016-3092
o The remediation logic (the validation of bufSize to the max of
bufSize or boundaryLength*2) is bound to the exact vulnerable
line of code
o The virtual fix is exactly the same remediation logic as the real
source-code fix
o After the virtual fix is applied, the vulnerable method is fully
remediated 28

29. Virtual Patching solves CVE-2016-3092
This approach would have allowed Equifax and any
other organization to instantly patch CVE 2017-5638.
29