Embed Size (px)
DESCRIPTION
An Aspect Oriented Security Framework . Viren Shah, Gary McGraw (PI) Cigital Labs [email protected]. Programmers should not have to be security experts! Security experts should not have to know what application every programmer is building!. - PowerPoint PPT Presentation
Citation preview
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
