VIT UNIVERSITY (Est.

u/s 3 of UGC Act 1956) Vellore - 632 014, TN, India

EXPERIMENTAL ROBUSTNESS EVALUATION OF JMS MIDDLEWARE

Submitted by: KUSHAL SHARMA (09BIT172) VAYUJ ASTHANA (09BIT171) CHANDAN ABHISHEK (09BIT176) ----------------------Faculty Signature

PROBLEM STATEMENT
The use of Java Message Service (JMS) for enterprise applications communication and integration is increasing very quickly. However, although JMS is frequently used in business-critical environments, applications are typically developed with the assumption that the middleware being used is robust, which is not always the case. Robustness failures in such environments are particularly dangerous, as they may originate vulnerabilities that can be maliciously exploited with severe consequences for the systems subject of attack. This project is an approach for the evaluation of the robustness of JMS middleware. Our approach is presented through a concrete example of evaluating the robustness of two well-known JMS solutions (JBoss MQ 3.2.8SP1, Oracle Glassfish MQ 4.4.2), in which several robustness and critical security related problems have been disclosed (including specification conformance disparities).

REQUIREMENTS
1) Software Requirement
a) JBoss MQ 3.2.8SP1: - The JBoss Application Server (AS) is the leading open source J2EE container today. Fully compliant with the J2EE 1.4 specification, it offers a container for Servlets and JSPs; an EJB container for Entity Beans, Session Beans, and Message Driven Beans; Web Services, database connection pooling, and JavaMail support. b) Oracle Glassfish MQ 4.4.2: - A complete message-oriented middleware platform. High quality, enterprise ready messaging; opens source and a community of developers and users. c) NetBeans IDE 7.0: - Introduces language support for development to the Java SE 7 specification with JDK 7 language features. The release also provides enhanced integration with the Oracle WebLogic server, as well as support for Oracle Database and Glassfish 3.1.

2) Hardware Requirements

a) Intel CoreTM i3-350M Processor 2.26 GHz b) Windows 7 Home Basic (64-bit) c) Hard Disk Drive 320 GB / Memory 3GB

3) Functional Requirements
a) Connections: - The connection factory must create connections that can be used to produce sessions.

b) Create or Read Messages: - A messaging client must connect to an agent that offers services like reading or creating messages. c) Send /Receive Messages: - Each session should be able to create message consumers or producers, which in turn have the ability to send/receive messages to/from a destination. d) Parameter Tampering: - For robustness testing modifying the message is necessary which can be done by using the basic set of mutation rule.

4) Non Functional Requirements

a) The result should help the developer to solve or wrap the identified problem. b) It should differentiate systems according to the number and type of error uncovered. c) Vendors with the help of result should be able to improve their JMS implementation and programmer to avoid JMS robustness problem.

Architecture Specification
a) JMS Programming Model (Without Message tampering)
Connection factory

Creates Connection

Creates Creates Message Producer Session Creates Message Consumer

Sends to

Creates

Receives from

Message Destination Destination

b) JMS Programming Model (With message tampering)

Connection factory

Connection

Creates Creates Message Producer Session Creates Message Consumer

Sends to

Creates

Receives from Modified message

Destination

Message

Destination

Mutation rule

Parameter Tampering

Produce

Implementation Module
hase 1: Valid message are created and sent
In this phase, the goal is to understand the behaviour of the JMS implementation without (artificial) faults.

Phase 2: Faults are injected and being sent

In this a parameter is chosen from the list of parameters not tested yet. According to the type of the selected parameters, a set of rules are applicable. Only one rule is selected in each injection period and all messages produced in this period are tampered according to that rule. Message delivery at the consumer is verified for correctness and consistency.

Phase 3: Involves regular message creation and sending with the goal of
exposing errors not revealed in phase 2 In this phase, we let the system run for a precedence period (at least twice the time necessary to the full workload) in order to check for abnormal behaviour not noticed in phase 2. * After phase 2, the system state is restored so that testing can continue with no accumulated fault effects. * The process repeats until there are no parameters to test.

Fault modes:
The robustness of the JMS middleware is characterized according to the following failure modes: a) Catastrophic b) Restart c) Abort d) Silent e) Hindering

-X-X-X-