1

Vulnerability Assessment

of Grid Software

James A. KupschComputer Sciences Department

University of Wisconsin

Condor Week 2007May 2, 2007

2

Security Problems Are Real

Everyone with a computer knows this.

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.

The grid community has been largely lucky (security through obscurity).

3

Many Avenues of Attack

InternetFirewall:

Attack web usingwww protocols

Compromised host Internal bad guy

wwwserver

We’re looking for attacks that exploit inherent weakness

in your system.

4

Impact of Vulnerabilities

FBI estimates computer security incidents cost U.S. businesses $67 billion in 2005 [

CNETnews.com]

Number of reported vulnerabilities each year is increasing [CERT stats]

0

2000

4000

6000

8000

1994 1998 2002 2006

5

Security Requires Independent Assessment

Fact #1:Software engineers have long known that testing groups must be independent of development groups

Fact #2:Designing for security and the use of secure practices and standards does not guarantee security

Independent vulnerability assessment is crucial…

…but it’s usually not done

6

Security Requires Independent Assessment

(cont.)You can have the best design in the world,

but can be foiled by …– Coding errors

– Interaction effects

– Operational errors

– Configuration errors

– …

• Vulnerability assessment proactively finds and eliminates vulnerabilities

7

Project Goals• Develop techniques, tools and procedures for

vulnerability assessment focusing on Grid software

• Apply to production software

• Improve the security of this software

• Educate developers about best practices

• Increase awareness about the need to do this

• Train and build a community of security specialists

8

Security Evaluation Process

• Overview– Insider - full access to source, documents, developers– Independent - no agenda, no blinders– First principles - let the process guide what to

examine

• Architectural analysis• Resource and privilege analysis• Component analysis• Codification of techniques and

dissemination

9

System Analysis(a.k.a. understanding the

system)Architectural analysis - the structure of the

system: what processes, their function, communication channels, trust relationships…

Resource analysis - objects in the system and the operations allowed

Privileges analysis - privilege model used internally by the software and by external resources

Data flow diagrams

10

Privileges - Root Install

Submit Host

Central Manager

User

submit

startd

schedd

shadow

Execute Host

startd

schedd

starter

User Job

collectornegotiator

1. Job Description File

2. Job ClassAd

1. Machine ClassAd

5. ReportMatch

6. Claim Host

7. ForkShadow

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

4. NegotiationCycle

7. forkStarter

root

user

Real UIDs

4.NegotiationCycle

5. Report Match 3. Job ClassAd

11

Component Analysis(a.k.a. finding the bad stuff)

• Audit the source code of a component using…

• First principles - use knowledge from previous analyses to guide search

• Look for vulnerabilities in a component

• Finds deeper problems not found by– Black box testing

– Threat driven vulnerability testing

12

Categories of Vulnerabilities

• Design flaws– Problems inherent in the design– Hard to automate discovery

• Implementation bugs– Improper use of the programming language, or of a

library API– Localized in the code

• Operational vulnerabilities– Configuration or environment

• Social engineering attacks– Valid users tricked into attacking

Occur about equally

13

Many Types of Vulnerabilities

Buffer overflowsInjection attacks

Command injection(in a shell)

Format string attacks(in printf/scanf)

SQL injectionCross-site scripting or

XSS(in HTML)

Directory traversalInteger vulnerabilities

Race conditionsNot properly

dropping privilegeInsecure permissionsDenial of serviceInformation leaksLack of integrity checksLack of authenticationLack of authorization

14

Integrating Vulnerability Assessment into the Development Process

• Writing Vulnerability Reports

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

• Vulnerability Disclosure Process

• Fixing vulnerabilities

• Announcing Vulnerabilitiesand Fixes

15

Systems Investigated• Univ. of Wisconsin’s Condor Project

– Batch queuing workload management system

– 600K lines of code, began 15 years ago

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

• SDSC’s Storage Resource Broker (SRB)– Distributed data store, with metadata and

federation capability

– 275K lines of code, began 9 years ago

– http://www.sdsc.edu/srb

• NCSA’s MyProxy (just starting)

16

Vulnerabilities Found

• 15 vulnerabilities in Condor documented– 2 from Condor staff– 1 in third-party library

• 6 vulnerabilities in SRB documented– 1 from SRB staff

• Most of these have existed for years in shipping releases

17

Summary of Project

• Develop local assessment expertise

• Develop assessment procedures

• Assessed and found vulnerabilities in Condor and SRB, starting MyProxy

• Codify and disseminate methodology and techniques

• Train developers to prevent vulnerabilities

18

Conclusion

• If you are developing middleware, you need to be doing this

• If you are using middleware, you need to make sure the people producing it are doing this

• If you are funding middleware, you need to make sure you are funding this

19

Security BOFThursday 3:00 – 4:00

Questions