Harden your Java Components !

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

2. Outline • FZI Overview • Motivation • Security Issues in Java Applications • Proposed Approach

3. 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“ FZI Karlsruhe – Software Engineering

4. FZI SE - People • Engineering methods, tools and processes for the efficient construction of high-quality software systems Real time systemsin Java Prof. Reussner Prof. Tichy Softwareprocesses Reorganization(Re-engineering) On components orientedsoftware construction ProcessEngineering Compiler construction Prof. Oberweis Prof. Goos On service oriented architectures Prof. Stucky FZI Karlsruhe – Software Engineering

5. FZI SE - Facts • Employees:28 scientific employees5 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% FZI Karlsruhe – Software Engineering

6. Outline • FZI Overview • Motivation • Security Issues in Java Applications • Proposed Approach

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

8. Motivation Technical issues • Motivating example: Dynamic SOP applications • What happens if the WebCamDriver component is a malware ? ‚WebCamDriver‘ Component 3. 1. 2. WebCam WebCam Component Repository PDA PDA ‚WebCamDriver‘ Component ‚MyContactList‘ Component Java SOP Platform (installed on the PDA)‏ Java SOP Platform (installed on the PDA)‏

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

10. Outline • FZI Overview • Motivation • Security Issues in Java Applications • Proposed Approach

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

12. Security Issues in Java Applications • Vulnerabilities in Java components: definition • Exposed Internal State • Reading or modification not explicitly through a method call • Excessive Rights • 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)‏ • Access to an object after the unregistration of the Service (or before its registration)‏ • Denial-of-Service • Blocking of client, server, or other clients of a server, components

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

14. Security Issues in Java Applications • Code weaknesses [Lai08] • Accessibility and extensibility • Input and output parameters • Classes • Objet construction • Serialization and deserialization • Standard APIs public final class WrappedState { // private immutable object private String state; // wrapper method public String getState() { return state; } // wrapper method public void setState(String newState) { // permission needed to set state securityManagerCheck(); inputValidation(newState); state = newState; } } // java.util.ArrayList is mutable //and non-final public void copyNonFinalInput (ArrayList list)‏ { // create new instance of //declared input type list = new ArrayList(list); doLogic(list); }

15. Security Issues in Java Applications • Other references • Overview • Gary McGraw, 12 rules [McGraw98] • Comprehensive catalogs • Findbugs 'Malicious Code' entries • http://findbugs.sourceforge.net/bugDescriptions.html • Cigital Java Security Rule Pack • http://www.cigital.com/securitypack/ • Malicious Bundle Catalog, Vulnerable Bundle Catalog [parrend2007INRIA-RR,parrend2008INRIA-RR]

16. Outline • FZI Overview • Motivation • Security Issues in Java Applications • Proposed Approach

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

18. Proposed Approach • Considered Vulnerabilities

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

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

21. 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 • clone() method if the class is cloneable • readObject(ObjectInputStream) if the class is serializable • have security check in final methods only

22. 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 • 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.

23. Proposed Approach • Goals of related attacks

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

25. Proposed Approach • Vulnerability definition <vs:vulnerability> <vs:vulnerabilityRef> <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:vulnerabilityRef> <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>sharedClasses</vs:exposition> <vs:location>allCode</vs:location> <vs:method> <vs:access>synchronized</vs:access> </vs:method> </vs:vulnerability>

26. Proposed Approach • Performances

27. 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 ?) • With more complex vulnerability • Complex issues need manual reviews

28. Perspectives • The VCA Tool • Lightweight approach for removing exploitable vulnerabilities in Java Components • 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

29. Documentation • Scientific publications • Enhancing Automated Detection of Vulnerabilities in Java Components, AreS 2009, http://www.rzo.free.fr/parrend09ares.php, march 2009 (accepted, talk to be done) • Software Security Models for Service-Oriented Programming (SOP) Platforms, http://www.rzo.free.fr/parrend08phd.php, PhD Thesis (document + talk), 9.12.2008 • Classification of Component Vulnerabilities in Java Service Oriented Programming (SOP) Platforms, http://www.rzo.free.fr/parrend08cbse.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_techNotes/owasp_security4mobileJava.pdf>

30. Contact FZI Software Engineering Domain http://www.fzi.de/se Dr. Pierre Parrend Research Scientist 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