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

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

14 October 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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 2004A.McNab – Security Middleware 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...