Middleware technology and software quality issues

1. Middleware technology and software quality issues Andrew McNab Grid Security Research Fellow University of Manchester

2. Outline • PKI and VOs • Local Policies • Services • VM environments • Native execution • Globus gatekeeper • Apache/GridSite • Software quality • Predictions / warnings 14 October 2004 A.McNab – Security Middleware

3. PKI and VO • LCG/EGEE/Grid3/OSG use X.509 Public Key / Certificate based credentials for authentication • “Secure against crypto attacks” • Implementations of X.509/TLS libraries may have vulnerabilities • LCG etc define authorization in terms of Virtual Organisation membership • Defined by published DN lists or Attribute Certificates • Leverages X.509 authentication infrastructure • Credential theft is greatest threat to these? 14 October 2004 A.McNab – Security Middleware

4. Local policies • LCG etc defines local access policies using Globus gridmap-file or policy language like GACL. • Again, these leverage authentication and authorization infrastructures. • Likely threats from attackers discovering policies that will permit access with credentials they hold • May include human error if we make policy files too hard to maintain (cf firewalls.) • Tension with Grids' desire to publish policy. • (cf current attacks spreading by looking at ssh .shosts file for other hosts to try with local ssh credential.) 14 October 2004 A.McNab – Security Middleware

5. Services • For example, a database with a Web Services frontend and some kind of authorization process. • Attacks may be possible against the DB or WS software • But most likely is some form of “legitimate” attack using stolen credentials or holes in local policies • We may see attackers using multiple services during an attack • eg gather information on services, and then run Denial of Service attacks on them one by one • These may be very difficult to distinguish from legitimate use of the services 14 October 2004 A.McNab – Security Middleware

6. Virtual Machines • Running jobs or agents in Virtual Machines limits the possibilities for escalation attacks • “I might be able to inject my evil code as a job, but I can't exploit vulnerabilities in the operating system to get root/admin access” (probably) • Java is the most common example • Designed from scratch with VM model in mind. • Also more heavyweight ways of creating VMs that look more like “real” system • Usermode Linux, Xen, VMware • Vulnerable to similar set of attacks as Services. 14 October 2004 A.McNab – Security Middleware

7. Native execution • However, many applications do not use Java • Existing codebases (millions of lines?) in other languages • Need non-VM environments for performance • In this case, need to expose “bare iron” of the worker machines to legitimate users • Dangers are that • (1) Malicious user injects their code instead of a legitimate job/agent • (2) Job execution service must have access to real environment. What if it has vulnerabilities? 14 October 2004 A.McNab – Security Middleware

8. Globus gatekeeper • Globus gatekeeper currently used by LCG etc does this in a traditional Unix-like way • It's a roll-your-own service written by Globus • Runs as root and spawns off processes as users as their job requests come in • This is the most straightforward way to do things • But this approach has some obvious problems • It's listening on the wire as root! • It is open source but has a very small developer community – are there more attacker eyeballs than developers looking at it? 14 October 2004 A.McNab – Security Middleware

9. Apache/GridSite • GridPP's GridSite also offers some types of native execution • Instead of writing our own network code or running as root, we leverage the existing Apache project • Millions of Apache websites; thousands of active developers of the code. • Listens as non-privileged user. • We just write the Grid Security extensions we need, and maintain them as an Apache module. • Patches are issued promptly by Apache when vulnerabilities discovered. 14 October 2004 A.McNab – Security Middleware

10. Quality & maintenance • Most attacks on pre-Grid systems are still because of vulnerabilities found in service software • Buffer overflows etc. • Grid software developers need to pay attention to this just as much as other Net service developers. • We should try to leverage as much well-maintained software as possible. • Design implementations that can be patched quickly, when vulnerabilities emerge. • Avoid duplication, go for modularity. • Think about the admin patching the service at 3am! 14 October 2004 A.McNab – Security Middleware

11. Predictions / summary • Current wave of attacks and inter-site escalations via ssh will continue. • Grid will continue to be “sexy”, on SlashDot, in Newscientist, in the spotlight etc. • Attackers will start using Grid/PKI credentials for inter-site attacks. • Attackers will notice the amount of roll-your-own services we use, with little code auditing/eyeballing. • Admins / applications / site management will revolt when attacks become noticeable and burdensome. • We will fall in love with maintainable services... 14 October 2004 A.McNab – Security Middleware