1 1 vulnerability assessment of grid software jim kupsch associate researcher, dept. of computer...

11

Vulnerability Assessmentof Grid Software

Jim KupschAssociate Researcher, Dept. of Computer Sciences

University of Wisconsin-Madison

Condor Week 2006

April 24, 2006

22

Security Problems Are Real

• Everyone with a computer knows this

• We’ve been lucky (security through obscurity)

• If you’re not seeing vulnerability reports and fixes for a piece of software, it doesn’t mean that it is secure. It probably means the opposite; they aren’t looking or aren’t telling.

33

Security Requires Independent Assessment

• Software engineers have long known that testing groups must be independent of development groups

• Designing for security and the use of the secure practices and standards does not guarantee security

44

Security Requires Independent Assessment (cont.)

• You can have the best design in the world, but can be foiled by…– Coding errors– Interaction effects– Human factors– Installation errors– Configuration errors– …

55

Project Goals

• Develop techniques, tools and procedures for vulnerability assessment

• Apply these to real software: Condor and recently SDSC’s SRB

• Improve the security of this software

• Educate developers about best practices in coding and design for security

66

Project Goals (cont.)

• Increase awareness in the grid and distributed systems community about the need for vulnerability assessments

• Build a community of security specialists

We consider the Condor team to be a leader in this effort to increase security.

77

Who We Are

• Professor Barton Miller

• Jim Kupsch, Associate Researcher– September to 2005 to present

• Mike Ottum, Research Assistant– January 2005 to August 2005

88

Security Evaluation Process

• Architectural analysis

• Resource and privilege analysis

• Component analysis

• Codification of techniques and dissemination

99

Architectural Analysis

• Create a detailed big picture view of the system• Document and diagram

– What executables exist and their function

– How users interact with them

– How executables interact with each other

– What privileges they have

– What resources they control and access

– Trust relationships

1010

Architectural Analysis (cont)

• Created by looking at existing documentation, talking to developers, experimenting with the application, and occasionally looking at the code

• Usually not well documented, or is spread across multiple documents

• Long time members of the Condor team learned things when presented with the diagrams

1111

Resource and Privilege Analysis

• Document and diagram– Resources in the system such as files, user jobs,

execution hosts, logs, etc– Operations allowed to be performed on a

resource– Privileges required for an operation on a

resource

1212

Component Analysis

• Audit the source code of a component

• Look for vulnerabilities in a component

1313

What Is a Vulnerability?

• A defect or weakness in system security procedures, design, implementation, or internal controls that can be exercised and result in a security breach or violation of security policy. - Gary McGraw, Software Security

• Examples include insecure file permissions, buffer overflows, and SQL injection

1414

How To Find Vulnerabilities

• Design level flaws:– Use the architectural, resource and privilege

analysis as a guide

• Implementation bugs:– Look at uses of suspect calls, such as strcpy

and popen– Look at array accesses to verify they are within

the boundaries of the array– Use automated analysis tools

1515

Vulnerability Disclosure Process

• Vulnerability report is created• Disclosed to developers• Allow developers to mitigate problem in a

release• Release abstracted report or information

along with a release• Publish full disclosure reports in

cooperation with developers

1616

Expected Project Results

• Produce architecture, resource and privilege documentation

• Find real vulnerabilities, and produce vulnerability reports and disclosures

• Codify methodology and techniques

• Disseminate methodology and techniques to others

1717

Condor Evaluation Status

• Currently in the component analysis stage of the evaluation process

• Still on-going

• We’re very happy with the cooperation of the Condor team with our project and their response to our reports

18

Submit Host

Central Manager

User

submit

startd

schedd

shadow

Execute Host

startd

schedd

starter

User Job

collectornegotiator

1. Job Description File

2. Job ClassAd

3. Job ClassAd

1. Machine ClassAd

5. Report Match

6. Claim Host

7. fork Shadow 8. Establish Communication Path 9. Set policy and fork User Job

4. Negotiation Cycle

7. forkStarter

Privileges - Root Install

root

condor

user

Real UIDs

nobody

4.Negotiation Cycle5. Report Match

1919

Condor Vulnerabilities

• Condor vulnerability fix process:– Create a new release containing a security fix and

announce an abstracted version of the vulnerability– Wait 4 weeks, to allow sites to upgrade– Publish a report with full disclosure at

http://www.cs.wisc.edu/condor/security

• Some reported vulnerabilities have been fixed and released. First fixes released in 6.7.18 and 6.6.11. Full disclosure reports available after April 24, 2006 at http://www.cs.wisc.edu/condor/security

2020

Condor Vulnerability Report

2121

More information

• We’re happy to talk during the breaks and meals• Security BOF tomorrow• condor-users@cs.wisc.edu email list to discuss

security issues in Condor and Condor issues in general

• http://www.cs.wisc.edu/condor/security will contain the vulnerability reports