An Aspect Oriented Security Framework

An Aspect Oriented Security Framework

Viren Shah, Gary McGraw (PI)Cigital Labsviren@cigital.com

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

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

Simplified View

Developers

Security Expert

SourceCode

SecurityExpertise

SecureApplication?

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.

Early Project Focus

The KISS Principle

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

Framework Layers

Infrastructure

Aspect Language

Aspect Customization

Meta-aspects

Basic parser, weaver and aspect language

Architecture

Source CodeSource Code Aspect Weaver

Woven SourceCode

Standard Compiler

Build Environment

Security AspectsConfiguration Tool

Crypto-StrongRandom Numbers

Buffer Overflowprotection

Secure Library Calls

StackGuard

Defaultconfigurationinializes tool

Security Expertise:describes program

transformation

May further configure,extend, or describe

aspects

Produces

Dictates how the weaverapplies aspects

Identified Future Research

Tool Produced by Cigital Labs

Security Experts and Cigital Labs

Meta Aspects AspectConfiguration

Source CodeDefault

(Secure) AspectConfiguration

Secure Application

Developer Responsibility

Security throughAspect Oriented Programming

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

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

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

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

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

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

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

Recent Project Focus

Think Global, Act Local

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?

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

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

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

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.

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:1Realloc:free::1:1

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); } } }}

AspectGenerator

Aspect Weaver

Customized Aspect

Application code

Secure Application code

Configurationfile

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

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.

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

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

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

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

Validation

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

Future Work

The long and winding road…

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

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

Questions?

Viren Shah: viren@cigital.com