An Aspect Oriented Security Framework

1. An Aspect Oriented Security Framework Viren Shah, Gary McGraw (PI) Cigital Labs viren@cigital.com

2. 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: Separation of concerns, knowledge encapsulation Goal: Aspect language for static transformations that express security fixes and preventative measures

3. Project Goals • Research and design an Aspect-Oriented framework to provide security-by-default • Explore viability of AOP for addressing range of security issues • Enable separation of concerns • Application developers need not be intimately familiar with security issues • Security experts need not know the details of every application

4. Simplified View Developers Source Code Secure Application ? Security Expert Security Expertise

5. Equal parts: Application code Security expertise templates (Aspects) Aspect Language (Csaw) Transformation anchor points (Point-cuts) Program transformer (Weaver) Language(s) parser Intermediate representation for code Compile with gcc. Serve hot. Recipe for Success

6. Early Project Focus The KISS Principle

7. Early Focus • Address most common exploits • Issues very implementation related • Keep It Simple • Keep the language simple • Simple and verifiable transformation process • Ensure ease-of-use • Security by default • Integrate with developer build environment • Aspect language easy to learn

8. Basic parser, weaver and aspect language Framework Layers Meta-aspects Aspect Customization Aspect Language Infrastructure

9. Architecture

10. Aspect Language • Research and development of a language specializing in security issues • What is a specialized security aspect language? • Semantic vs. syntactic point-cuts • Transformation descriptors • Scope + point-cut parameters + transformation directives • Flexible and extensible to accommodate different solutions • Easy to use for programmers • Early mistakes • Too flexible • Too many point-cuts • Resulting Language • Simple • Extensible underlying framework to enable future extensions

11. Aspect Weaver • Design and build a transformation engine to enable the aspect-oriented approach • Resembles a secondary-stage pre-processor • Takes pre-processed code as input • Processes code by mapping aspect transformations to code locations • Outputs code ready to be compiled by a standard compiler • Primary engineering task was to build an in-memory intermediate representation • Enable transformations • Optimizes performance

12. Aspects • Started with most common classes of exploits • Buffer Overruns • Format String • TOCTTOU • Small aspect size (< 100 lines of code) • Minimal impact on application code (kinda - sorta) • Negligible effect on performance

13. Problem Overwriting buffer variables may can result in malicious code being executed Malicious attackers can perform arbitrary actions with an elevated privilege. Approach Bookend buffers with canaries inside a struct Check canaries whenever buffer goes out of scope Any attempt to overwrite the buffer will kill the canaries Aspect: Buffer Overrun • Protects only stack variables • Negligible Performance Penalty

14. Problem Use of file names instead of file descriptors in programs may leave short windows of opportunity during which assumptions are incorrect. Malicious attackers can read or write arbitrary files with an elevated privilege. Approach Reorder a target program’s use of file access functions in terms of file descriptors. Subsequent file calls will necessarily access the expected file. Aspect: TOCTTOU • Current implementation may cause exhaustion of file descriptors • Covers over 50 system calls

15. Problem Improperly generated format strings, if used with user input, can result in execution of arbitrary code Malicious attackers can can execute arbitrary code with an elevated privilege. Approach Ensures anomalous format strings can’t be used Few target functions that need to be modified Aspect: Format String • Current implementation is simple and can be expanded • No performance penalty

16. Phase I Summary • Designed and developed an Aspect-Oriented Security Framework • Aspect Language • Designed an aspect language for security • Aspect Weaver • Researched and implemented solutions to common implementation-level security problems • Buffer overruns • Race conditions • Format string

17. Recent Project Focus Think Global, Act Local

18. From bricks to walls • IMPLEMENTATION • Low level flaws are important, but are overemphasized • ITS4: www.cigital.com/its4 • SourceScope • Uses a parser to build an AST (commercial package) • AOP first pass • ARCHITECTURE • A risk analysis of a high-level spec has real value • The earlier in the software lifecycle, the better • Focus on Architecture • System view • Revise design based on the results of analysis • Can the AOP tool push into this space?

19. Aspects • Develop aspects that address “design-level” security issues • Input sanitization • Protecting communications channels • Event ordering enforcement • RTTI implementation • Aspects are more than just straight implementation fixes • Aspects require global information

20. Problem Programs can be adversely affected by anomalous input. (understatement of the century) One small part of this problem is that special meta-characters may be passed to a shell. Approach Check the parameters of functions such as popen() and exec() for pipes, semicolons, and the like. May cause problems if such meta-characters are an expected part of the shell parameters! Now we need the ability to customize an aspect Aspect: Input sanitization Example: The classic CGI-bin problem

21. Problem System designers must protect confidential transmissions Many channels inadvertently created with no protection Designers often make poor encryption choices Implementers make common mistakes Approach Identify all outbound data channels Weave in use of appropriate encryption libraries (avoiding common mistakes) Aspect: Protecting channels Example: Netscape’s biff agent (POP3) Also standard ftpd

22. Problem Programs, especially libraries, can be put into anomalous states due to non-enforcement of sequencing requirements. Initialization functions or functions pairs are prime examples of this. Approach Track function calls dynamically using in-memory push-down automata. Use automated aspect generator to create aspects from simple configuration language. Aspect: Event Ordering

23. Goal was to have a generic aspect that would handle different function ordering scenarios Write an aspect with complex logic to facilitate this, or Write an aspect generator that would create a customized aspect based on the desired configuration Chose the latter solution to offload complexity out of the aspect and application Aspect: Event Ordering aspect bufferAspect { bufferProtect< void protect(char * buffer, int size, int canary1, int canary2)> { before { canary1 = CANARY; canary2 = CANARY; } after { if( canary1 != CANARY) { fprintf(stderr,"Canary dead.... Exiting\n"); exit(0); } if( canary2 != CANARY) { fprintf(stderr,"Canary dead... Exiting\n"); exit(0); } } } } Customized Aspect Malloc:free::1:1 Realloc:free::1:1 Aspect Generator Configuration file Secure Application code Aspect Weaver Application code

24. Problem Languages like C enable developers to write unsafe programs Exploits like buffer overruns can be traced back to weak type safety Approach Use an aspect to weave in Run-Time Type Identification (RTTI) into the application code Keep track of a variable’s type and enforce correct type transfers Similar approach to Cyclone, Cqual, Vault Aspect: RTTI for C

25. Aspect: RTTI for C • Simple use example: • Transform functions like strcpy() so that they query type and size information from the RTTI knowledge base • This would prevent the source buffer from overwriting and overrunning the destination buffer. • More complex use: • At every assignment, check to see if the lvalue is compatible with the rvalue • This will ensure that casts are safe • Several ways to do this, including allowing one “re-interpreting cast” per variable • Possible config file to express “proper” casts • Aspect and underlying infrastructure nearly complete.

26. Infrastructure Changes • Question: So how did “Moving from Bricks to Walls” affect the Aspect framework? • Answer: Not as much as we had originally thought • Aspect Language • Added 2 more point-cuts • Aspect Weaver • Basic changes to support variable shunting • Most additions occurred at the Aspect Customization layer

27. Aspect Configuration: • Input Sanitization • Protecting Channels • RTTI • Aspect Generator • Event Ordering Extended infrastructure, language and customizable aspects Basic parser, weaver and aspect language Basic parser, weaver and aspect language Framework Layers Meta-aspects Aspect Customization Aspect Language Infrastructure

28. Project Technical Summary • Designed and developed an Aspect-Oriented Security Framework • Aspect Language • Aspect Weaver • Researched and implemented solutions to common implementation-level security problems • Buffer overruns, Race conditions, Format string • Moved to addressing higher-level issues • Channel protection • RTTI • Started addressing aspect customization issues

29. Is AOP viable for security? • Does an Aspect-Oriented Security Framework represent a workable solution? • Advantages: • Seamless integration into build process • Global implementation of solutions • Disadvantages: • With such a powerful hammer, everything’s a nail • Tied to the code-level

30. Validation

31. Experimentation • Aspects validated on several popular and widely-used open-source applications • Wu-ftpd • Bind • OpenSSL • Used the buffer overrun aspect on wu-ftpd in-house on the production Cigital ftp server (< 20 minutes response time) • Also used the AOP security aspects on in-house applications • Currently performing testing and validation tasks for the implemented aspects

32. Future Work The long and winding road…

33. Continuing Tasks • Finish a more comprehensive RTTI aspects • Explore limits of AOP tool in this area • Research survivability aspects • Test on wider range of applications • Complete validation metrics for all aspects

34. Future Work • Meta-aspects • Aspect Collisions • Aspect Inheritance • Aspect Customization • Reliability and survivability focus • Will our AOP infrastructure work without major changes? • How does the changed focus affect infrastructure features • Push harder towards design/architecture-level capabilities

35. Questions? Viren Shah: viren@cigital.com