Manuel Brugnoli, Elisa Heymann UAB Vulnerability Assessment of Middleware Packages Supplied by EMI: VOMS Core Case Manuel Brugnoli, Elisa Heymann UAB

First Principles Vulnerability Assessment (FPVA) Contents Outline First Principles Vulnerability Assessment (FPVA) VOMS Core VOMS Core assessment using FPVA Conclusions

First Principles Vulnerability Assessment (FPVA) “Is a primarily analyst-centric (manual) approach to assessment, whose aim is to focus the analyst’s attention on the parts of the software system and its resources that are mostly likely to contain vulnerabilities that would provide access to high-value assets”* * James A. Kupsch, Barton P. Miller, Eduardo César, and Elisa Heymann, "First Principles Vulnerability Assessment" (extended version), MIST Project Technical Report, September 2009.

First Principles Vulnerability Assessment (FPVA) to identify the major structural components of the system, including modules, threads, processes, and hosts. Architecture to identify the key resources accessed by each component, and the operations supported on those resources. Resources identifies the trust assumptions about each component, answering such questions as how are they protected and who can access them? Privileges is to examine each component in depth. A key aspect is that this step is guided by information obtained in the first three steps, helping to prioritize the work so that highvalue targets are evaluated first. Components artifacts produced by this step are vulnerability reports, perhaps with suggested fixes, to be provided to the middleware developers. Dissemination

VOMS Core assessment using FPVA Virtual Organization Membership Service (VOMS) serves as a central repository for user authorization information, providing support for sorting users into a general group hierarchy, keeping track of their roles, etc. VOMS Core is the server that receives requests from a VOMS client and returns information about the user. We worked with VOMS Core 2.0.2.

Step 1: VOMS 2.0.2 Architecture Analysis User Host VOMS Server Host Command Line VOMS Client GSI Connection VOMS daemon Command Line Ancillary Utilities DB Web Web Browser HTTPS Command Line VOMS Admin Client VOMS Admin (Tomcat) SOAP over SSL OS privileges user daemon root DB privileges VO_Server

Step 1: VOMS Client-Server Interaction

Step 2: VOMS Core 2.0.2 Resource Analysis

Step 2: VOMS Core 2.0.2 Resource Analysis

Step 3: VOMS Core 2.0.2 Privilege Analysis

Step 4: VOMS Core 2.0.2 Component Analysis Resource permissions: Evaluated the permissions of files that have a high security value (certificate private keys, database and configuration files). The permissions of these files appeared to be correct.

Step 4: VOMS Core 2.0.2 Component Analysis User privileges: Client side: No privilege problems in the client commands. Server side: The voms daemon runs with root operating system privileges. Evaluated the source code looking for flaws that may compromise the server. No privilege problems were found.

Step 4: VOMS Core 2.0.2 Component Analysis Dangerous functions: Evaluated the use of functions that commonly result in security problems, such as system or exec family functions. No vulnerabilities related to dangerous functions were found.

Step 4: VOMS Core 2.0.2 Component Analysis Authentication Issues: Mutual authentication is performed between the client and server. VOMS design makes the system quite strong, and reduces many possible threats.

Step 4: VOMS Core 2.0.2 Component Analysis Network Layer Security: VOMS server creates a secure communication channel via Globus GSI with the VOMS Clients. The use of a encrypted channel provides strong end-to-end data encryption and integrity.

Step 4: VOMS Core 2.0.2 Component Analysis Injection Attacks: Evaluated the source code to ensure VOMS correctly parses and checks the arguments passed through the command line. Appropriate parsing is performed to protect against command injection vulnerabilities.

Step 4: VOMS Core 2.0.2 Component Analysis Buffer overflows: VOMS Core is written in C/C++ → Checked for potential buffer overflow problems. No dangerous behavior was detected.

Step 4: VOMS Core 2.0.2 Component Analysis Denial of Service Attacks: A DoS vulnerability was discovered and reported to the VOMS developers. This vulnerability is caused by lack of limits on the number of simultaneous connections. Full details about this were reported in the vulnerability report VOMS-CORE-2011-0001.

Conclusions Conclusions No serious security problems in VOMS Core 2.0.2 was found: The attack surface in VOMS Core is very small. VOMS Core correctly parses and checks the arguments sent from the client. The VOMS server uses a forking server model to handle all requests from VOMS clients. The recommended operational configuration of a VOMS server node is a highly secured host with limited local user access and other services. All communication between the VOMS server and VOMS clients is secure. A DoS vulnerability was found.

Thank you!!! ¿Questions?