Vulnerability Assessment of Grid Software

1
Vulnerability Assessmentof Grid Software

• Jim Kupsch
• Associate Researcher, Dept. of Computer Sciences
• University of Wisconsin-Madison
• Condor Week 2006
• April 24, 2006

2
Security Problems Are Real

• Everyone with a computer knows this
• Weve been lucky (security through obscurity)
• If youre not seeing vulnerability reports and
  fixes for a piece of software, it doesnt mean
  that it is secure. It probably means the
  opposite they arent looking or arent telling.

3
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

4
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

5
Project Goals

• Develop techniques, tools and procedures for
  vulnerability assessment
• Apply these to real software Condor and recently
  SDSCs SRB
• Improve the security of this software
• Educate developers about best practices in coding
  and design for security

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

7
Who We Are

• Professor Barton Miller
• Jim Kupsch, Associate Researcher
• September to 2005 to present
• Mike Ottum, Research Assistant
• January 2005 to August 2005

8
Security Evaluation Process

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

9
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

10
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

11
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

12
Component Analysis

• Audit the source code of a component
• Look for vulnerabilities in a component

13
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

14
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

15
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

16
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

17
Condor Evaluation Status

• Currently in the component analysis stage of the
  evaluation process
• Still on-going
• Were very happy with the cooperation of the
  Condor team with our project and their response
  to our reports

18
Privileges - Root Install
Central Manager
Real UIDs
4. Negotiation Cycle
root
collector
negotiator
condor
user
1. Machine ClassAd
nobody
Execute Host
5. Report Match
Submit Host
startd
4.Negotiation Cycle 5. Report Match
User
3. Job ClassAd
startd
7. fork Starter
schedd
6. Claim Host
schedd
1. Job Description File
starter
2. Job ClassAd
7. fork Shadow
8. Establish Communication Path
submit
9. Set policy and fork User Job
shadow
User Job
19
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/se
  curity

20
Condor Vulnerability Report
21
More information

• Were happy to talk during the breaks and meals
• Security BOF tomorrow
• condor-users_at_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