Aspect Oriented Security Tim Hollebeek, Ph.D.

Overview Background and Motivation Aspect Oriented Programming Aspect Oriented Security Strategy and Progress

State of the World 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 What we know isn’t being applied to real software!

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

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

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

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

Aspect Oriented Security 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 Goal: Aspect language for static transformations that express security fixes and preventative measures Need: Portability of concerns, as well as separation

Architecture

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

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

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

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

Future Work 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

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