we research for you background and tool for building secure java applications contact: dr. pierre...
TRANSCRIPT
We Research for You
Background and tool for building secure Java applications
Contact: Dr. Pierre [email protected]
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