security of opendaylight platform
TRANSCRIPT
OpenDayLight Security
Security response and secure engineering processes
David Jorm: [email protected]
Outline
● Introduction
● Common Java security vulnerabilities
● Security response best practices
● Secure engineering best practices
● ODL security: current status
● ODL security: vision
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!
Common Java security vulnerabilities
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.”
CVE-2014-0121● hawt.io project includes web-based admin
terminal: http://localhost:8181/hawtio/hawtio-karaf-terminal/term
● CVE-2014-0120: CSRF
● AuthenticationFilter.java
M1: CVE-2014-0121● Remote unauthenticated command execution
● Live demo
● Patch for AuthenticationFilter.java
● Full patch commit: https://github.com/hawtio/hawtio/commit/5289715e4f2657562fdddcbad830a30969b96e1e
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
OWASP XXE guidelines
● It wasn’t always this way:
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...
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?
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
Try searching on github – you will find many other instances of this issue
More effective searching? Binary-only distributions?
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
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.
XStreamReflection-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
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-deserialization-flaws-part-2-xml-deserialization/
Security response best practices
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
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)
Secure engineering best practices
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
Open Source Secure Engineering
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/
ODL security: current status
ODL: Security Response● Security reporting mechanism
● Dedicated team with a private mailing list and basic process for handling issues
● Security advisories page
ODL: Secure Engineering● Great analysis performed in May 2014:
https://wiki.opendaylight.org/view/CrossProject:OpenDaylight_Security_Analysis
● Little progress implementing any of the recommendations from this analysis
● Definition of a threat model is currently underway via mailing list discussions
ODL security: vision
SDN: Threat Model
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
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:OpenDaylight_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
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)
Questions?