Talk by David Jorm on the state of Security in Java frameworks, and more specifically OpenDaylight. He also talks about his vision for where the platform should get to for delivering on the SDN promise.

1. OpenDayLight
Security
Security response and secure
engineering processes
David Jorm: david.jorm@gmail.com

2. Outline
● Introduction
● Common Java security vulnerabilities
● Security response best practices
● Secure engineering best practices
● ODL security: current status
● ODL security: vision

3. Introduction: David Jorm
● Software engineer for 15 years, climatology domain
● Last 5 years focusing on security, mainly Java
● Managed Red Hat's Java middleware security team
● Now a product security engineer for IIX, and a
member of the ODL security response team
● I love finding new 0day and popping shells!
david.jorm@gmail.com

4. Common Java security vulnerabilities

5. Authentication bypasses
● Logic errors in security constraints
● Incorrect paths, path wildcards
● HTTP verb/method tampering: security
constraints restricted to specific
verbs/methods
● HEAD method used for tampering. RFC2616:
“In particular, the convention has been established that the GET and HEAD
methods SHOULD NOT have the significance of taking an action other
than retrieval”
“The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request.”

6. CVE-2014-0121
● hawt.io project includes web-based admin
terminal:
http://localhost:8181/hawtio/hawtio-karaf-termina
l/term
● CVE-2014-0120: CSRF
● AuthenticationFilter.java

7. M1: CVE-2014-0121
● Remote unauthenticated command execution
● Live demo
● Patch for AuthenticationFilter.java
● Full patch commit:
https://github.com/hawtio/hawtio/commit/52897
15e4f2657562fdddcbad830a30969b96e1e

8. XXE (everywhere!)
● General entity attacks
● Parameter entity attacks
● Most Java APIs do not disable entity expansion by
default
● Relies on developers following best practices, e.g.
from OWASP

9. OWASP XXE guidelines
● It wasn’t always this way:

10. Netconf CVE-2014-5035
● Netconf API processes user-supplied XML (also
restconf)
● Example vuln code: controller / opendaylight/netconf/netconf-
util/src/main/java/org/opendaylight/controller/netconf/util/xml/XmlUtil.java
● Example exploit...

11. RCE – EL interpolation
● Various expression languages are commonly used
in Java libraries
● MVEL is one example
● Generally speaking, if an attacker can supply EL,
they can execute arbitrary code on the server
● How can an attacker supply EL?

12. CVE-2013-4486
● Zanata is an open source translation memory
platform built on Seam
● Seam evaluates EL in log messages. If code
performs string concatenation with user-supplied
input to create the log messages, an attacker can
inject EL (Credit: Adrian Hayes)
● Zanata would log user-supplied strings using string
concatenation

13. RCE – XML deserialization
● Alternative XML-based serialization formats
● JAXB is the standard (no known flaws)
● Other XML serialization libraries exist, and have
exposed security issues leading to RCE
● We’ll look at two examples: XMLDecoder and
XStream

14. XMLDecoder
● XMLDecoder’s XML format can represent a series of
methods that will be called to reconstruct an object
● If XMLDecoder is used to deserialize untrusted
input, arbitrary code can be injected into the XML
● Example: Restlet CVE-2013-4221. Fixed by
removing vulnerable functionality.

15. XStream
Reflection-based deserialization
Has a special handler for dynamic proxies
(implementations of interfaces)
Attackers can provide XML representing a dynamic
proxy class, which implements the interface of a
class the application might expect
Dynamic proxy implements a handler that calls
arbitrary code when any members of the
deserialized class are called
Vulnerable components: Spring OXM, Sonatype
Nexus, Jenkins

16. XStream in Jenkins
● Jenkins XML API uses XStream to deserialize input
● Access to XML API -> RCE (but not such a huge
deal)
● Live demo
● Solution: blocked DynamicProxyConverter in
XStream wrapper class
● Upstream solution: whitelisting, with dynamic
proxies excluded by default
● More information:
https://securityblog.redhat.com/2014/01/23/java-dese
rialization-flaws-part-2-xml-deserialization/

17. Security response best practices

18. Open Source Security Response
● All information public
● Not just source code: bug trackers, mailing lists,
etc.
● Security requires the opposite approach:
information must be kept private until patches are
available
● How do you handle this in the context of an open
source project?
● A dedicated security team with a documented
process

19. Open Source Security Response
● Dedicated mechanism for reporting security issues,
separate to normal bugs
● Dedicated team with a documented process for
responding to these reports
● Ability to quickly build a patch asynchronous to
normal release schedules
● Clear documentation of the issue in an advisory,
including references to patch commits (advantage
of open source)

20. Secure engineering best practices

21. Open Source Secure Engineering
● No well established best practices
● Few good examples in the open source world.
Proprietary software currently does this better, e.g./
microsoft's SDLC.
● OpenStack is one good example
● Separate VMT and OSSG teams

22. Open Source Secure Engineering

23. Open Source Secure Engineering
● Secure development guidelines (relies on
developers to implement)
● Developer training (I just did this for everyone in
the room, but it is“expensive” and difficult to roll
out in a virtual environment)
● Automated QE/CI jobs to catch issues and enforce
standards, e.g. via static analysis
● Static analysis with 56 bug patterns
● http://h3xstream.github.io/find-sec-bugs/

24. ODL security: current status

25. ODL: Security Response
● Security reporting mechanism
● Dedicated team with a private mailing list and
basic process for handling issues
● Security advisories page

27. ODL: Secure Engineering
● Great analysis performed in May 2014:
https://wiki.opendaylight.org/view/CrossProject:Ope
nDaylight_Security_Analysis
● Little progress implementing any of the
recommendations from this analysis
● Definition of a threat model is currently underway
via mailing list discussions

28. ODL security: vision

29. SDN: Threat Model

30. ODL: Security Vision
● High performing security response team
● Ability to co-ordinate issues across the community
development team and affected vendors of
OpenDayLight distributions
● Geographically distributed and able to quickly
respond in all timezones

31. ODL: Security Vision
● The OpenDaylight Security Analysis performed in
May 2014 has captured some great details on the
threat model and steps that should be taken as
part of a proactive secure engineering effort:
https://wiki.opendaylight.org/view/CrossProject:Ope
nDaylight_Security_Analysis
● These steps fall into three categories:
● 1) Documentation, e.g. separating the
management network from the data network
● 2) Code changes, e.g. removing default credentials
● 3) Process/infrastructure changes, e.g. establishing
a security response process and building security
tests into the QE/CI system

32. ODL: Security Vision
● Industry leading secure engineering function
● Security docs (e.g. best practice install guide)
● Developer training as part of committer onboarding
● Automated QE/CI jobs to catch issues and
regressions
● No documented secure coding standard (automate
any standards in QE/CI jobs)

34. Questions?