Otros Asuntos Importantes

Vulnerabilities are design or coding flaws in systems that provoke the threats described above to be exploited by attackers. Formal testing for vul- nerabilities tests the absence of exploitable vulnerabilities, whereas pen- etration testing tests for the existence of those weaknesses. After pre- senting both approaches, we summarize those with a list of the existing vulnerability classes.

Computer Security 49

Vulnerability classi cation

It is an ongoing industrial effort to standardize the definition of vulnera- bilities. The Oasis-Open consortium (Heineman, 2004) published a spec- ification about attacks directed against HTTP-based applications. Being affected by these attacks does not necessarily imply that the HTTP imple- mentation of the application is vulnerable. Merely the attack chose HTTP as transport communication protocol, but could have used other commu- nication path as well. Therefore, a broader approach to define vulnerabili- ties would be helpful to provide a standardized documentation of the entry path of the vulnerability (such as HTTP, RMI, JDBC), the vulnerability it- self (the protocol implementation, the event handler), and the resulting security compromise (detection, disclosure, deception, usurpation).

The Landwehr Framework One of the first classification frameworks for vulnerabilities (among others) is the Landwehr flaw classification scheme (Landwehr et al., 1994). The taxonomy (Figure 2.5) of software flaws em- phasizes on three aspects:

• The genesis, the type of the bug is concerned (such as being a covert channel)

• The time of introduction in that the vulnerability was it introduced, as in the development or maintenance phase

• The location of the vulnerability endetails whether the issue is an operation system problem or affects the application layer only. We follow the categorization given by Bishop (2002).

Incomplete or inconsistent parameter validation leads to tainted data within

the application. Knowing internal structures and decision paths in the application allows an attacker to handcraft input parameter com- binations to gain control over the application. An example for incon- sistent parameter validation was found in the JBOSS J2EE server

Genesis Time of In- troduction Location Intentional Inadvertent Development Maintenance Operation Software Hardware Malicious Non-Malicious Validation Error Domain Error Serialization Error Identification/Authorization Inadequate

Boundary Condition Violation Other exploitable logic Requirement / Specification Source code Object code OS/Runtime Support/ Middleware Application Trojan Horse Trojan Horse Time Logic Bomb Covert channel Other System Identification Memory Management Process Management Device Management File Management Identification/Authorization Other unknown Privileged Utilities Unprivileged Utilities Replicating Non-Replicating Storage Timing

Computer Security 51

3.2.1 where an attached %00 character revealed the source code of the JAVA server pages files instead of dynamically generate HTML results, as shown by Schönefeld (2003o).

Implicit sharing of (privileged or confidential) data between JAVA appli- cations violates the principle of least common mechanism. An at- tacker may vulnerabilities in and application to acquire data of an- other application due to their shared data. During this research, we discovered a covert channel vulnerability in the standard JAVA- Plugin for Internet browsers. Setting global variables to arbitrary values could be misused to violate the sandbox protection model, which is the containment enforced for JAVA applets by the applet specification. This problem was demonstrated in (Schönefeld, 2003i).

Inadequate Deserialization occurs often between the moments of object

creation and object initialization and object usage. Explicit object creation, object cloning or creation of objects may create objects within JAVA and other object-oriented languages. To exchange data with a remote communication partner, a node uses a serialized data representation. Naive implementation of these documented and un- documented constructor methods may omit holistic parameter vali- dation semantics. An attacker may invoke methods on an object in an intermediate state or inject objects with illegal states. The java. io.ObjectInputStream class allows deserialization of data. This al- lows exploiting vulnerabilities in parameter validation. An attacker can exploit this vulnerability to inject objects with illegal states into remote runtime environments. Those scenarios will are presented in Chapter 8.5.

Violable prohibition and limits such as edge conditions using extreme val-

ues are a typical misuse case that attackers apply to provoke over- flow of data types that will put objects to an undefined state. This

was used in a proof-of-concept to exploit a set of vulnerabilities in the java.util.zip package. In this package an integer overflow condition was exploitable to trigger a denial-of-service condition in a trusted JDK core library. The effects of this problem are presented in Chapter 8.3.

Exploitable logic errors and side effects of instructions trigger side effects

by performing legal actions. These attacks misuse holes in the spec- ification. By coupling accessed resources to an exploitable error con- dition, an attacker leads the system to an undefined state. We found the JDBC interface provided by the JBOSS application server to be vulnerable. It accepted java statements embedded in SQL state- ments. This could be misused to trigger side effects on the operat- ing system layer. A detailed description is provided in Chapter 8.6.

Common Weaknesses The Common Weaknesses Enumeration project(Mitre Corporation, 2009a) follows the goal to provide a systematic presentation of vulnerabilities. Their taxonomy provides a subdivision into three parts:

• Insecure Interaction Between Components • Risky Resource Management

• Porous Defenses

Within these categories the project identified 25 important vulnerability types. These are listed in Table 2.9. We will come back to these categories when discussing the identified antipatterns in JAVAapplications.

Vulnerability collections

Vulnerabilities may appear in multiple facades, a condition that makes it difficult to refer to a particular type of vulnerability. The CVE (Com- mon Vulnerabilities and Exposures) dictionary (Mitre Corporation, 2007a)

Computer Security 53

aims to share knowledge about vulnerabilities. The project is community- based where vendors and security researchers contribute their knowledge on published vulnerabilities. The results are freely available.

The data collected in the CVE dictionary is useful to illustrate how the type vulnerabilities shifted over the years from low-level operating system problems to application level problems.