Security Risks in Clouds and Grids

1. Security Risks in Clouds and Grids Condor Week May 5, 2011 Elisa Heymann Computer Architecture andOperating Systems Department UniversitatAutònoma de Barcelona Elisa.Heymann@uab.es Barton P. Miller James A. Kupsch Computer Sciences Department University of Wisconsin bart@cs.wisc.edu 1

2. 1 4 5 2 3 Efficient execution of SPMD Applications on Multicore Environments Multicore Environment Objective Hierarchical communication architecture • Maximum Speedup • Efficiency over a defined • threshold Problem Edge tile Idle Time Internal tile SPMD Tile Core Communications SuperTile allows to overlap the internal computation with edge communication How? Methodology SPMD Application Message Passing Interface Ideal Size of Supertile Ideal Number of Core

3. ParallelApplicationSignaturefor performance prediction Instrumentation ParallelApplication Base Machine BuildParallelApplicationSignature (CoordinatedCheckpoint + Phases + Weights) PatternsIdentification Collection data ExtractPhases and Weights ParallelApplicationModel Target Machine B Target Machine A S S Time of eachPhasebyweight Time of eachPhasebyweight Prediction Prediction

4. Possible Threat? • Clouds and Gridshavedatabaseswithmanagement and operationalinformation • Denial of Service: • Preventupdates in thedatabase 4

5. Possible Threat? • Hijack machines • Process escapes Cloud/Grid/control: Keepsforking and exitingto escape detection. ? Evil JobPID n Evil JobPID 3 Evil JobPID 2 Evil JobPID 1 . . . fork fork fork 5

6. Possible Threat? • Cloud/Grid Accounting System • Maintains a Grid-wide view of resource utilization. • Job Submission (Priority in the batch queue, CPU time, Memory usage) • Storage (Disk usage, Tape storage) • Accounting Information easily available to people (web interface) and to applications (Web Services) • Use the Accounting System for bad purposes. 6

7. 7 Possible Threat?

8. 8 Real Threat! Found and Fixed

9. 9 What the bad guys can do • Gain root access • Privilege escalation • Gain higher privilege access (admin, condor) • Hijack machines • Attack the process running there

10. 10 What the bad guys can do • Injections • Command • SQL • Directory traversal • Log • Stringuser= request.getParameter("user"); • Stringpassword= request.getParameter("password"); • Stringsql= "select * fromuserwhereusername=' " + user + " ' and password=' " + password+" ' "; ' or '1'='1'--

11. 11 What the bad guys can do • Injections • Command • SQL • Directory traversal • Log • Denial of Service (DoS)

12. 12 What the bad guys can do • Injections • Command • SQL • Directory traversal • Log • Denial of Service (DoS)

13. 13 Why do we care • Machines belonging to a cloud/grid site are accessible from the Internet • Hundred of thousands of machines are appealing • Those machines are continuously probed: • Attackers trying to brute-force passwords • Attackers trying to break Web applications • Attackers trying to break into servers and obtain administrator rights

14. 14 Why do we do it • SW has vulnerabilities • Cloud and Grid SW is complex and large • Vulnerabilities can be exploited by legal users or by others

15. 15 Why do we do it • Attacker chooses the time, place, method, … • Defender needs to protect against all possible attacks (currently known, and those yet to be discovered)

16. 16 Key Issues for Security • Need independent assessment • Software engineers have long known that testing groups must be independent of development groups • Need an assessment process that is NOT based solely on known vulnerabilities • Such approaches will not find new types and variations of attacks

17. Our Piece of the Solution Space First Principles Vulnerability Assessment: An analyst-centric (manual) assessment process. You can’t look carefully at every line of code so: Don’t start with known threats … … instead, identify high value assets in the code and work outward to derive threats. • Start with architectural analysis, then identify key resources andprivilege levels, component interactionsand trust delegation, then focused component analysis. 17

18. First Principles Vulnerability AssessmentUnderstanding the System Step 1: Architectural Analysis • Functionality and structure of the system, major components (modules, threads, processes), communication channels • Interactions among components and with users

19. OS privileges condor & root user ArchitecturalAnalysis: Condor Condor execute host 1. fork 1. fork 5. Negotiator cycle Condor submit host Condor execute host Stork server host stork_server negotiator collector startd starter master shadow schedd submit master master master job 5. Negotiator cycle 6. Report match 1. fork 1. fork 1. fork 6. Report match 2. machine ClassAd 4. job ClassAd 8. fork 8. fork 7. claim host 3. submit job ClassAd 10. start job 9. establish channel

20. First Principles Vulnerability AssessmentUnderstanding the System Step 2: Resource Identification • Key resources accessed by each component • Operations allowed on those resources Step 3: Trust & Privilege Analysis • How components are protected and who can access them • Privilege level at which each component runs • Trust delegation

21. Resource Analysis: Condor (b) Unique Condor Checkpoint Server Resources OS privileges condor root user (a) Common Resources on All Condor Hosts Send and Receive Checkpoints (with Standard Universe Jobs) generic Condor daemon ckpt_server User Job starter shadow (c) Unique Condor Execute Resources (d) Unique Condor Submit Resources log etc spool Operational Log Files Condor Config Condor Binaries & Libraries Operational Data & Run-time Config Files System Call Forwarding and Remove I/O (with Standard Universe Jobs) execute ckpt user Job Execution Directories Checkpoint Directory User’s Files

22. First Principles Vulnerability AssessmentSearch for Vulnerabilities Step 4: Component Evaluation • Examine critical components in depth • Guide search using: Diagrams from steps 1-3 Knowledge of vulnerabilities • Helped by Automated scanning tools

23. First Principles Vulnerability AssessmentTaking Actions Step 5: Dissemination of Results • Report vulnerabilities • Interaction with developers • Disclosure of vulnerabilities

24. Our Experience Condor, University of Wisconsin Batch queuing workload management system15 vulnerabilities600 KLOC of C and C++ SRB, SDSC Storage Resource Broker - data grid5 vulnerabilities280 KLOC of C MyProxy, NCSA Credential Management System5 vulnerabilities25 KLOC of C glExec, Nikhef Identity mapping service5 vulnerabilities 48 KLOC of C Gratia Condor Probe, FNAL and Open Science Grid Feeds Condor Usage into Gratia Accounting System3 vulnerabilities1.7 KLOC of Perl and Bash Condor Quill, University of Wisconsin DBMS Storage of Condor Operational and Historical Data6 vulnerabilities7.9 KLOC of C and C++ 24

25. Our Experience Wireshark, wireshark.orgNetwork Protocol Analyzer in progress 2400 KLOC of C Condor Privilege Separation, Univ. of Wisconsin Restricted Identity Switching Module21 KLOC of C and C++ VOMS Admin, INFN Web management interface to VOMS data 35 KLOC of Java and PHP CrossBroker, UniversitatAutònoma de Barcelona Resource Mgr for Parallel & Interactive Applications97 KLOC of C++ 25

26. Our Experience ARGUS 1.2, HIP, INFN, NIKHEF, SWITCH gLiteAuthorizationServicein progress glExec 0.8,Nikhef Identity mapping service 26

27. 27 What do we do • Make cloud/grid software more secure • Make in-depth assessments more automated • Teach tutorials for users, developers, admin, managers: • Security risks • Vulnerability assessment • Secure programming

28. 28 Who we are • Elisa Heymann • Eduardo Cesar • Jairo Serrano • Guifré Ruiz • Manuel Brugnoli • Bart Miller • Jim Kupsch • Karl Mazurak • RohitKoul • Daniel Crowell • Wenbin Fang

29. Security Risks in Clouds and Grids Elisa Heymann Elisa.Heymann@uab.es Barton P. Miller James A. Kupsch bart@cs.wisc.edu http://www.cs.wisc.edu/mist/ http://www.cs.wisc.edu/mist/papers/VAshort.pdf 29