190 likes | 212 Views
Vulnerability Assessment of Grid Software. James A. Kupsch Computer Sciences Department University of Wisconsin Condor Week 2007 May 2, 2007. Security Problems Are Real. Everyone with a computer knows this.
E N D
Vulnerability Assessmentof Grid Software James A. Kupsch Computer Sciences DepartmentUniversity of WisconsinCondor Week 2007 May 2, 2007
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).
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
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]
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
Security BOF Thursday 3:00 – 4:00 Questions