Vulnerability Assessment of Grid Software

1. Vulnerability Assessmentof Grid Software James A. Kupsch Computer Sciences DepartmentUniversity of WisconsinCondor Week 2007 May 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. Firewall: www server Internet Many Avenues of Attack We’re looking for attacks that exploit inherent weaknessin your system. Attack web using www protocols Internal bad guy Compromised host

4. 8000 6000 4000 2000 0 1994 1998 2002 2006 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]

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 anddissemination

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

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. Occur about equally 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

13. Buffer overflows Injection attacks Command injection(in a shell) Format string attacks(in printf/scanf) SQL injection Cross-site scripting or XSS(in HTML) Directory traversal Integer vulnerabilities Race conditions Not properlydropping privilege Insecure permissions Denial of service Information leaks Lack of integrity checks Lack of authentication Lack of authorization Many Types of Vulnerabilities

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 BOF Thursday 3:00 – 4:00 Questions