1. 1 Update on the Vulnerability Assessment Effort Elisa Heymann Computer Architecture and Operating Systems Department Universitat Autònoma de Barcelona Elisa.Heymann@uab.es

2. 2 EMI: Software to Assess ›gLite –Argus 1.2 –gLexec 0.8 –VOMS Core –CREAM: Computing Resource Execution And Management –WMS: Workload Management System

3. 3 EMI: Software to Assess ›Unicore –TSI: The Target System Interface –Gateway

4. 4 Current Status ›VOMS Admin 2.0.18: done! ›Java, JSP y javascript ›38 KLOC ›2.5 months of work

5. 5 Current Status ›VOMS Admin 2.0.18: done ›2 Critical vulnerabilities ›Cross Site Request Forgery attacks => an attacker will be able to execute arbitrary VOMS Admin actions. ›Persistent Cross Site Scripting vulnerabilities => non- privileged users can store javascript code in the database, which will be executed by other users. ›2 Non-critical vulnerabilities ›Fields of the web interface that display information about the users certificates are vulnerable to Persistent Cross Site Scripting vulnerabilities. ›Reflected Cross Site Scripting vulnerabilities => non- privileged users can submit javascript code to VOMS Admin, and this code is reflected back to the user browser.

6. 6 Current Status ›gLexec 0.8: done! ›C ›13 KLOC ›5 months of work

7. 7 Current Status ›gLexec 0.8: done! ›3 Critical vulnerabilities ›Lack of cleanup of jobs => allows a prior user of the uid to attack the current user's jobs and files. ›Reuse of local uids => attack another job running later. ›1 Non-critical vulnerabilities ›A job can prevent the job completed log record from being written to the glexec log.

8. 8 Current Status ›Argus 1.2: done! ›Java, C, scripting languages ›42 KLOC ›5 months of work ›No vulnerabilities found. ›Report on what was assessed and why Argus worked fine.

9. 9 Were are we now ›VOMS Core 2.0.2: Just started –Vincenzo Ciaschini & Valerio Venturi –C: 30753 –C++: 10138 –exp: 7955 –java: 7754 ›Started: May 2011 ›Expected duration: 6 months

10. 10 Vulnerability Assessment@EMI Apply FPVA to relevant EMI Middleware –Assess the SW –Generate vulnerability reports A vulnerability is considered only when we produce an exploit for it.

11. First Principles Vulnerability Assessment Understanding 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

12. CE Host authZ service Host PDP WN Host PEP Server WN job gLExec PAP Admin Tool (Edit Policy) Administrator 2 3 4 5 6 9 10a LRMS WMS CREAM User (UI) 1a1a RB Host 1b1b Argus 1.2 Architecture PAP 7 8 D’ E’ PAP (Policy Administration Point) → Manage Policies. PDP (Policy Decision Point) → Evaluate Authorization Requests. PEP (Policy Enforcement Point) → Process Client Requests and Responses. B A C’ Admin data-flow User data-flow F’ DtDt HTTPS PEP Client (Lib) Communications among PAP, PDP, and PEP Server via HTTPS CLI EtEt /etc/init.d/pdp reloadpolicy /etc/init.d/pepd clearcache FtFt 10b Run jobExit gLExec OS privileges userbatch user External Component Administrator & root root

13. User: X’ = Optional steps Xt = Periodic steps 1.User submits a job described as a JDL expression. 2.CREAM receives a job execution request from WMS (1a) or the User (1b) directly. 3.CREAM sends the job execution request to the LRMS. 4.LRMS sends the job to the WN for its execution. 5.WN sends an authorization request to gLExec, and gLExec interacts with PEP Server using an LCMAPS plug-in which uses the PEP Client library to check if the mapping request can be satisfied. 6.PEP Client sends the XACML request to the PEP Server. 7.PEP Server sends the authorization request (XACML) to PDP for evaluation. 8.PDP evaluates the authorization request and sends the response to PEP Server. 9.PEP Server sends to PEP Client the authorization response which can be allowed (10a) or denied (10b). 10.gLExec runs job using local identity only if the authorization response is allowed. Admin: A.Administrator edits policies using the command line interface (CLI). B.PAP Admin Tool writes policies and policy sets and make them available at PAP. C’.Administrator reloads policies since Argus updates the policies in regular intervals. D’.PDP sends a retrieve policies request to PAP. E’.PAP sends policies (XACML) to PDP. F’. Administrator sends a clear cache request to PEP Server for clearing the response cache. Dt.PDP connects periodically to the remote PAP to refresh the repository policy. Et.PAP sends the policies (XACML) to PDP. Ft.PEP Server clears periodically its cache, since PEP Server keeps a short response cache. Argus 1.2 Architecture

14. First Principles Vulnerability Assessment Understanding 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

15. authZ service Host (PAP Component) conf lib logs TRUSTED_CA etc/ grid_security pap_ configuration.ini pap_ authorization.ini hostcert.pem host has key signed, hostkey.pem Argus 1.2 Resources Readable Owner World certificates PAP logging bin pap-admin repository sbin pap- standalone.sh pap- deploy.sh XML Policies OS privileges userbatch user External Component Administrator & root root

16. authZ service Host (PDP Component) conf lib logs TRUSTED_CA etc/ grid_security pdp.ini hostcert.pem host has key signed, hostkey.pem Argus 1.2 Resources certificates sbin env.sh logging.xml Readable Owner World pdpctl.sh PDP Repository policy OS privileges userbatch user External Component Administrator & root root

17. authZ service Host (PEP Server Component) conf lib logs TRUSTED_CA etc/ grid_security pepd.ini Argus 1.2 Resources sbin env.sh logging.xml Readable Owner World pepdctl.sh hostcert.pem host has key signed, hostkey.pem certificatesgrid-mapfilegroupmap file gridmapdirvomsdir PEP Server Cached Policies OS privileges userbatch user External Component Administrator & root root

18. First Principles Vulnerability Assessment Search 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

19. First Principles Vulnerability Assessment Taking Actions Step 5: Dissemination of Results –Report vulnerabilities –Interaction with developers –Disclosure of vulnerabilities

20. 20 Vulnerability Report ›One report per vulnerability ›Provide enough information for developers to reproduce and suggest mitigations ›Written so that a few sections can be removed and the abstracted report is still useful to users without revealing too much information to easily create an attack.

21. 21 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 –Valid users tricked into attacking Occur about equally

22. 22 How do You Respond? ›Identify a team member to handle vulnerability reports. ›Develop a remediation strategy: –Study the vulnerability report. –Use your knowledge of the system to try to identify other places in the code where this might exist. –Study the suggested remdiation and formulate your response. –Get feedback from the assessment team on your fix – very important for the first few vulnerabilities. ›Develop a security patch release mechanism. –This mechanism must be separate from your release feature/upgrade releases. –You may have to target patches for more than one version.

23. 23 How do You Respond? Develop a notification strategy: ›What will you tell and when? ›Users are nervous during the first reports, but then become your biggest fans. ›Often a staged process: 1.Announce the vulnerability, without details at the time you release the patch. 2.Release full details after the user community has had a chance to update, perhaps 6-12 months later. ›Open source makes this more complicated! The first release of the patch reveals the details of the vulnerability.