Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Aspect Oriented Security Framework Viren Shah, Gary McGraw (PI) Cigital Labs

Similar presentations

Presentation on theme: "An Aspect Oriented Security Framework Viren Shah, Gary McGraw (PI) Cigital Labs"— Presentation transcript:

1 An Aspect Oriented Security Framework Viren Shah, Gary McGraw (PI) Cigital Labs

2 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: Separation of concerns, knowledge encapsulation

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 Security Expert Source Code Security Expertise Secure Application ?

5 Recipe for Success 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.

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 Framework Layers Infrastructure Aspect Language Aspect Customization Meta-aspects Basic parser, weaver and aspect language

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 Aspect: Buffer Overrun 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 Protects only stack variables Negligible Performance Penalty

14 Aspect: TOCTTOU 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. Current implementation may cause exhaustion of file descriptors Covers over 50 system calls

15 Aspect: Format String 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 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: –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 Aspect: Input sanitization 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 Example: The classic CGI-bin problem

21 Aspect: Protecting channels 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) Example: Netscape’s biff agent (POP3) Also standard ftpd

22 Aspect: Event Ordering 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.

23 Aspect: Event Ordering 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 Malloc:free::1:1 Realloc:free::1:1 aspect bufferAspect { bufferProtect { 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); } Aspect Generator Aspect Weaver Customized Aspect Application code Secure Application code Configuration file

24 Aspect: RTTI for C 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

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 Framework Layers Infrastructure Aspect Language Aspect Customization Meta-aspects Basic parser, weaver and aspect language  Aspect Configuration:  Input Sanitization  Protecting Channels  RTTI  Aspect Generator  Event Ordering Extended infrastructure, language and customizable aspects Basic parser, weaver and aspect language

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:

Download ppt "An Aspect Oriented Security Framework Viren Shah, Gary McGraw (PI) Cigital Labs"

Similar presentations

Ads by Google