Vulnerability Assessment of Middleware Packages Supplied by EMI: VOMS Core Case

www.egi.eu EGI-InSPIRE RI-261323

EGI-InSPIRE


Vulnerability Assessment of Middleware Packages Supplied by

EMI: VOMS Core Case

Manuel Brugnoli, Elisa Heymann

UAB


Outline

• First Principles Vulnerability Assessment

(FPVA)

• VOMS Core

• VOMS Core assessment using FPVA

• Conclusions

Contents


“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)


Architecture

Resources

Privileges

Components

Dissemination

to identify the major structural components

of the system, including modules, threads,

processes, and hosts.

to identify the key resources accessed by

each component, and the operations

supported on those resources.

identifies the trust assumptions about each

component, answering such questions as

how are they protected and who can

access them?

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.

artifacts produced by this step are

vulnerability reports, perhaps with

suggested fixes, to be provided to the

middleware developers.

First Principles Vulnerability Assessment (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.

VOMS Core assessment using FPVA


VOMS Server Host

DB

VOMS Admin (Tomcat)

VOMS daemon

User Host

Web

Browser

VOMS

Client

VOMS Admin

Client

HTTPS

SOAP over SSL

Ancillary

Utilities

GSI Connection

OS privileges

user daemon root

DB privileges

VO_Server

Command Line

Command Line

Web

Command Line

Step 1: VOMS 2.0.2 Architecture Analysis


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


• 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.



• 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.



• Authentication Issues:

• Mutual authentication is performed between

the client and server.

• VOMS design makes the system quite strong,

and reduces many possible threats.



• 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.



• 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.



• Buffer overflows:

• VOMS Core is written in C/C++ → Checked for

potential buffer overflow problems.

• No dangerous behavior was detected.



• 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.


¿Questions?

Thank you!!!

Technology

Vulnerability Assessment of Middleware Packages Supplied by EMI: VOMS Core Case