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

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 SDSC’s 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 • We’re 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 negotiator collector 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/security

20. Condor Vulnerability Report

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