Aspect Oriented Security

1. Tim Hollebeek, Ph.D. tim@cigital.com Aspect Oriented Security www.cigital.com

2. Overview • Background and Motivation • Aspect Oriented Programming • Aspect Oriented Security • Strategy and Progress

3. Then (1980’s): Network applications vulnerable to compromise due to well known software flaws Now: Network applications vulnerable to compromise due to well known software flaws Why don’t we have secure software? Many subtleties Too much to know Programming is hard Popular languages are not designed with security in mind State of the World What we know isn’t being applied to real software!

4. Nature of Software Security • Security expertise is rare, and expensive to produce • Software is large and complex • Auditing is often impractical • Yet: only as secure as “weakest link” Ability to apply security concerns uniformly throughout code would be useful

5. Aspect Oriented Programming Developer Source Code Application ? Developer Source Code Source code organized in terms of concerns instead of in terms of objects

6. Aspect Oriented Security Developer is not a security expert Developers Source Code Secure Application ? Security Expert Security Expertise

7. Aspect Oriented Security Developer is not a security expert Developers Source Code Secure Application Weaver Security Expert Security Aspect Security expertise is application independent

8. Programmers should not have to be security experts! Security experts should not have to know what application every programmer is building! Abstract security concerns away and deal with them separately Build technology to weave in the appropriate constructs Write once, apply everywhere Aspect Oriented Security Need: Portability of concerns, as well as separation Goal: Aspect language for static transformations that express security fixes and preventative measures

9. Architecture

10. Scope Language: C Traditional applications • Many security problems • Buffer overflows, race conditions, unsafe library calls, TOCTOU, unchecked error codes, audit logging, critical sections (and others!) • Problems are well known and well understood • Many insecure programs could immediately benefit from working tool • Results can be easily applied to new languages

11. Theory • Aspects must be able to make moderately complex transformations to existing code • Aspects must be portable, must integrate cleanly with other aspects without prior knowledge • Merging multiple aspects • Based on the idea that semantics of original program are preserved • Theory and experience from AOP community is helpful here

12. Key issues • Security experts need sufficiently powerful primitives for expressing interesting transformations • Tool must place little or no burden on users • Filman and Friedman: “Aspect Oriented Programming is Quantification and Obliviousness” OOPSLA 2000

13. Progress to Date • Build Integration • weaving integrates seamlessly into development environment • Designed and implemented infrastructure for future weavers • Prototype aspect language and weaver • syntax and semantics similar to AspectJ • explored what can be expressed • evaluated requirements/design considerations for further improvements

14. Aspect collision Reusable aspects Aspect inheritance Aspect extension (e.g., error recovery) Aspect language improvements Extensibility Expressiveness Configuration and build issues Usability Aspect configuration Integration Linker, library issues Other tools Design and implement security aspects, distribute tool Future Work

15. Conclusion Aspect Oriented Security • provides uniform framework for building secure software automatically • C source • Other languages • Separation of concerns • Developer does not require security expertise • Security expert does not require knowledge of program • Security aspects are reusable and extensible • Automatic • Integrated with normal build process