We Research for You

Background and tool for building secure Java applications

Contact: Dr. Pierre Parrendparrend@fzi.de

Software EngineeringFZI Forschungszentrum Informatik

FZI Overview Motivation Security Issues in Java Applications Proposed Approach

Outline

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

FZI Overview

3 19.04.23FZI Karlsruhe – Software Engineering

Alignment: „Transfer of technology innovative solutions in information technologies“

Engineering methods, tools and processes

for the efficient construction of high-quality software systems

FZI SE - People

4 19.04.23FZI Karlsruhe – Software Engineering

ProcessEngineering

Reorganization(Re-engineering)

Compiler construction

Softwareprocesses

On components oriented software

construction

Real time systemsin Java

Prof. Goos

Prof. Oberweis

Prof. Tichy

On service oriented architectures

Prof. Reussner

Prof. Stucky

FZI SE - Facts

19.04.23FZI Karlsruhe – Software Engineering5

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 Overview Motivation Security Issues in Java Applications Proposed Approach

Outline

The evolution of software

• New security challengeso Integration of components from various originso At development time (Web Servers, etc) or at runtime (OSGi)

MotivationTechnical issues

MonolithicApplications

Component-basedApplications

Service-orientedProgramming (SOP)

Applications

Motivating example: Dynamic SOP applications

• What happens if the WebCamDriver component is a malware ?

Motivation Technical issues

PDA

ComponentRepository

WebCam

Java SOP Platform(installed on the PDA)

‚WebCamDriver‘Component

1.2.

PDA

WebCam

3.

Java SOP Platform(installed on the PDA)

‚WebCamDriver‘Component‚MyContactList‘

Component

MotivationEconomic issues

How to minimise the cost of security• Reduce the impact of

vulnerabilities• Cost of vulnerabilities

o Minimal when flaws are repared early

o Grows dramatically latter in the life-cycle

• Components are integratedo During development

Correction is possibleo At runtime

Detection at best

9

Capers Jones, Applied software measurement: assuring productivity and quality, 1999.

FZI Overview Motivation Security Issues in Java Applications Proposed Approach

Outline

Attack vectors• Exploitation of the platform• Exploitation of the 3d 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 Rightso Access to method or data contrary to intended security policy

• Life-cycle abuseo 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)

• Denial-of-Serviceo Blocking of client, server, or other clients of a server, components

Security Issues in Java Applications

Security Issues in Java Applications

Dangerous functions [Long05]• Type safety

o Using the same name for sev. classes is confusing

• Public Fieldso Break encapsulation

• Inner Classeso Private inner classes are made

protected at compilation

• Serializationo Serialize Data can be read easily

• JVM Tool Interface (TI)o Enables JVM mgt from outside

• Debuggingo Based on JVM-TI

• Monitoring and Managemento JMX enables broad access to

system

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-finalpublic void copyNonFinalInput (ArrayList list){ // create new instance of //declared input type list = new ArrayList(list); doLogic(list); }

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]

Security Issues in Java Applications

FZI Overview Motivation Security Issues in Java Applications Proposed Approach

Outline

Proposed Approach

Harden components• The public code is exposed

o 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

SharedClasses

InternalCode

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 methodo all constructorso clone() method if the class is cloneableo readObject(ObjectInputStream) if the class is serializable

• 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

methodo 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

o According to the exposition of the codeo Based on a meta-model of Object-Oriented Classeso Uses XML policies

Vulnerability definition Set the reaction when vulnerabilities are found

o Development use Warnings

o Runtime use Rejection

• Currently a prototype

Proposed Approach

Vulnerability definition

Proposed Approach

<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 (Vulnerabilitycan 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>

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

Proposed Approach

The VCA Tool• Lightweight approach for removing exploitable

vulnerabilities in Java Componentso 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

Perspectives

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>

Documentation

Contact

30