Harden your Java Components Background and tool

Harden your Java Components ! Background and tool for building secure Java applications Contact: Dr. Pierre Parrend parrend@fzi. de We Research for You Software Engineering FZI Forschungszentrum Informatik

Outline § § FZI Overview Motivation Security Issues in Java Applications Proposed Approach

FZI Overview § 20 years transfer of technology in public interest § Sales volume: 8 millions € (2005) § More than 130 projects of different size per year § Approx. 90 employees, thereof 75 scientists Alignment: „Transfer of technology innovative solutions in information technologies“ 3 FZI Karlsruhe – Software Engineering 3/19/2018

FZI SE - People § Engineering methods, tools and processes for the efficient construction of high-quality software systems Prof. Reussner Real time systems in Java Software processes Reorganization (Re-engineering) Compiler construction Prof. Goos Prof. Tichy On components oriented software construction Process Engineering Prof. Oberweis On service oriented architectures Prof. Stucky 4 FZI Karlsruhe – Software Engineering 3/19/2018

FZI SE - Facts § Employees: 28 scientific employees 5 post doc § approx. 25 students § since 20 years practicing software engineering § for the present 20 current projects, over 80 completed cooperations with the free economy § Sales approx. 2, 800, 000 EUR § Share of the industry earnings: approx. 40% 5 FZI Karlsruhe – Software Engineering 3/19/2018

Outline § § FZI Overview Motivation Security Issues in Java Applications Proposed Approach

Motivation Technical issues § The evolution of software Monolithic Applications Component-based Applications Service-oriented Programming (SOP) Applications • New security challenges Integration of components from various origins o At development time (Web Servers, etc) or at runtime (OSGi) o

Motivation Technical issues § Motivating example: Dynamic SOP applications ‚Web. Cam. Driver‘ Component 3. 1. 2. Web. Cam Component Repository PDA ‚My. Contact. List‘ Component Java SOP Platform (installed on the PDA) ‚Web. Cam. Driver‘ Component PDA Java SOP Platform (installed on the PDA) • What happens if the Web. Cam. Driver component is a malware ?

Motivation Economic issues § How to minimise the cost of security • Reduce the impact of • vulnerabilities Cost of vulnerabilities Minimal when flaws are repared early o Grows dramatically latter in the life-cycle o • Components are integrated o During development § Correction is possible o At runtime § Detection at best 9 Capers Jones, Applied software measurement: assuring productivity and quality, 1999.

Outline § § FZI Overview Motivation Security Issues in Java Applications Proposed Approach

Security Issues in Java Applications § Attack vectors • Exploitation of the platform • Exploitation of the 3 d party bundles

Security Issues in Java Applications § Vulnerabilities in Java components: definition • Exposed Internal State o Reading or modification not explicitly through a method call • Excessive Rights o Access to method or data contrary to intended security policy • Life-cycle abuse Access to a class after the uninstallation of a component (or before its installation) o Access to an object after the unregistration of the Service (or before its registration) o • Denial-of-Service o Blocking of client, server, or other clients of a server, components

Security Issues in Java Applications § Dangerous functions [Long 05] • Type safety o Using the same name for sev. classes is confusing • Public Fields o Break encapsulation • Inner Classes o Private inner classes are made protected at compilation • Serialization o Serialize Data can be read easily • JVM Tool Interface (TI) o Enables JVM mgt from outside • Debugging o Based on JVM-TI • Monitoring and Management o JMX enables broad access to system

Security Issues in Java Applications § Code weaknesses [Lai 08] • Accessibility and extensibility • Input and output parameters // java. util. Array. List is mutable //and non-final public void copy. Non. Final. Input (Array. List list) { // create new instance of //declared input type list = new Array. List(list); do. Logic(list); } • Classes public final class Wrapped. State { // private immutable object private String state; // wrapper method public String get. State() { return state; } // wrapper method public void set. State(String new. State) { // permission needed to set state security. Manager. Check(); input. Validation(new. State); state = new. State; } } • Objet construction • Serialization and deserialization • Standard APIs

Security Issues in Java Applications Other references Overview Gary Mc. Graw, 12 rules [Mc. Graw 98] Comprehensive catalogs Findbugs 'Malicious Code' entries http: //findbugs. sourceforge. net/bug. Descriptions. html Cigital Java Security Rule Pack http: //www. cigital. com/securitypack/ Malicious Bundle Catalog, Vulnerable Bundle Catalog [parrend 2007 INRIA-RR, parrend 2008 INRIA-RR]

Outline § § FZI Overview Motivation Security Issues in Java Applications Proposed Approach

Proposed Approach § Harden components • The public code is exposed o Vulnerabilities can be directly exploited • Internal code can have more relaxed constraints Shared Objects Shared Classes Internal Code § Repartition of vulnerabilities • Shared classes (libraries) • Shared objects (services, EJBs, etc. )

Proposed Approach § Considered Vulnerabilities

Proposed Approach § A controversial example • Synchronized code • Do you consider this a vulnerability ?

Proposed Approach § Components should • only have dependencies on components they trust • never used synchronized statements that rely on third • party code provide a hardened public code implementation following given recommendations

Proposed Approach § Shared Classes should • provide only final static non-mutable fields • set security manager calls during creation in all required places at the beginning of the method all constructors o clone() method if the class is cloneable o read. Object(Object. Input. Stream) if the class is serializable o • have security check in final methods only

Proposed Approach § Shared Objects (e. g. SOP Services) should • only have basic types and serializable final types • • as parameter perform copy and validation of parameters before using them perform data copy before returning a given object in a method o returned object should be either a basic type or serializable. • not use Exception that carry any configuration • information, and not serialize data unless a specific security mechanism is available never execute sensitive operations on behalf of other components.

Proposed Approach § Goals of related attacks

Proposed Approach § Automated vulnerability identification • VCA (Vulnerable Component Analysis) tool • Identification of vulnerabilities According to the exposition of the code o Based on a meta-model of Object-Oriented Classes o Uses XML policies o § Vulnerability definition § Set the reaction when vulnerabilities are found o Development use § Warnings o Runtime use § Rejection • Currently a prototype

Proposed Approach § Vulnerability definition <vs: vulnerability> <vs: vulnerability. Ref> <vs: catalog_id>vb</vs: catalog_id> <vs: src_ref>java</vs: src_ref> <vs: type>class</vs: type> <vs: id>15</vs: id> </vs: vulnerability. Ref> <vs: message>Synchronized method call. If the method call is blocked for any reason (infinite loop during execution, or delay due to an unavailable remote resource), all subsequent clients that call this method are freezed (Vulnerability can be exploited with class-sharing only through a static call). </vs: message> <vs: exposition>shared. Classes</vs: exposition> <vs: location>all. Code</vs: location> <vs: method> <vs: access>synchronized</vs: access> </vs: method> </vs: vulnerability>

Proposed Approach § Performances

Proposed Approach § Tools bring an important improvement • Relieve the human auditors from tiresome work • Efficient and cheap training of software developers § Tools can not do everything • 50 % of vulnerabilities are currently identified • Need of further development (Owasp Summer of code ? ) o With more complex vulnerability • Complex issues need manual reviews

Perspectives § The VCA Tool • Lightweight approach for removing exploitable vulnerabilities in Java Components o Could be extended for further OO Languages • Complementary to existing bug finding tools • Hardening components is necessary to build secure dynamic applications § FZI Services • Security audit of object-oriented software • Security Training

Documentation § Scientific publications • Enhancing Automated Detection of Vulnerabilities in Java Components, Are. S 2009, • • http: //www. rzo. free. fr/parrend 09 ares. php, march 2009 (accepted, talk to be done) Software Security Models for Service-Oriented Programming (SOP) Platforms, http: //www. rzo. free. fr/parrend 08 phd. php, Ph. D Thesis (document + talk), 9. 12. 2008 Classification of Component Vulnerabilities in Java Service Oriented Programming (SOP) Platforms, http: //www. rzo. free. fr/parrend 08 cbse. php, scientific paper + talk, 15. 10. 2008 § Technical Reports • More Vulnerabilities in the Java/OSGi Platform: A Focus on Bundle Interactions, Pierre • Parrend, Stéphane Frenot, INRIA Research Report RR-6649, September 2008. Java Components Vulnerabilities - An Experimental Classification Targeted at the OSGi Platform, Pierre Parrend, St phane Frenot, INRIA Technical Report n° 6231, june 2007. § Other talks • Talk at the Swiss OWASP Group meeting, 24. 07. 2007: Dependability for Java Mobile Code - a Pragmatic Research View <http: //www. rzo. free. fr/docs_tech. Notes/owasp_security 4 mobile. Java. pdf>

Contact FZI Software Engineering Domain http: //www. fzi. de/se Dr. Pierre Parrend Research Scientist 30 FZI Forschungszentrum Informatik Haid-und-Neu-Str. 10 -14 D-76131 Karlsruhe Tel. : +49 -721 -9654 -620 Fax: +49 -721 -9654 -621 http: //www. fzi. de/se