1 1 vulnerability assessment of grid software jim kupsch associate researcher, dept. of computer...
TRANSCRIPT
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• [email protected] 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