source analysis for security

Source Analysis for Security

Trent Jaeger

March 29, 2004

Example 1

sys_fcntl(int fd, ...) {struct file *filp; ...filp = fget(fd); ...err = security_ops->file_ops->fcntl(filp, ...); ...do_fcntl(fd, ...); ...

}

do_fcntl(int fd, ...) { ...err = fcntl_setlk(fd, ...); ...

}

fcntl_setlk(int fd, ...) { ...struct file *filp; ...filp = fget(fd); /* is this the one checked in sys_fcntl? */

Example 2

get_free_buffer(struct stripe_head *sh, …) {struct buffer_head *bh;unsigned long flags;

save_flags(flags);cli();if ((bh = sh->buffer_pool) == NULL)

return NULL;sh->buffer_pool – bh->b_next;bh->b_size = b_size;restore_flags(flags);return bh;

}

Example 3

sys_fcntl(int fd, ...) {err = security_ops->file_ops->fcntl(filp, ...); ...do_fcntl(fd, ..., filp); ...

}

do_fcntl(int fd, ..., struct file *filp) { ...case F_SETLEASE:

fcntl_setlease(fd, filp, ...); ...case F_SETOWN:

err = security_ops->file_ops->set_fowner(filp, ...); ... if (err) ... break; filp->f_owner.pid = arg; filp->f_owner.uid = current->uid; filp->f_owner.euid = current->euid; ...}

Example 3 (con’t)

fcntl_setlease(int fd, struct file *filp, ...) { ... if (my_before != NULL) { error = lease_modify(my_before, arg, fd, filp);

...} ...}

lease_modify(..., int fd, struct file *filp, ...) { ... if (arg == F_UNLCK) { /* should these be f_setowner auth'd ? */ filp->f_owner.pid = 0; filp->f_owner.uid = 0; filp->f_owner.euid = 0; filp->f_owner.signum = 0;}

Example 4

int notify_change(struct dentry * dentry, struct iattr * attr) { struct inode *inode = dentry->d_inode; …if (inode->i_op && inode->i_op->setattr) {

error = security_inode_setattr(dentry, attr); if (!error)

error = inode->i_op->setattr(dentry, attr);…

}

Find Software Bugs

Education– Difficult to know how code will be used

Testing– Misses many code paths, time consuming

Manual Inspection– Tedious and error prone

Compiler checking– Context independent

4GL– Incomplete and don’t know how source code will be used

Assurance– Extremely costly and complex – what do we do about existing code?

Limited Source Code Analysis

Source code is the level security is defined– Problems manifest in errors in code (although design can

be a problem too) Compilers can check for various properties

– Rules on program source Programmers can express some properties

– Semantic properties– Must specify correctly (no/few false negatives)– Must not be too conservative (few false positives)– Like to be robust with code changes

Source Code Analysis

Covert source code into a model Convert property into a computation on

model Report positive cases (violate/meet property) Determine if cases are true or false Resolve true cases Refine model or property and repeat

Some Properties

Never/always do X– Never use floating point in kernel

Do X rather than Y Always do X before/after Y

– LSM mediation (Example 1) Never do X before/after Y In situation X, do (not) Y

– Re-enable disabled interrupts (Example 2) In situation X, do Y rather than X

Program Models

Abstract Syntax Tree Control flow Data flow Def-use chain Aliases Type constraints …

Abstract Syntax Tree

Func_declSys_fcntl

var_declStruct file *filp

Expr_stmt=

Var_declfilp

call_declFget(fd)

Expr_stmt=

Var_declerr

Cmpd_stmtSecurity_op

call_decldo_fcntl

Func_declDo_fcntl

Expr_stmt=

Var_declerr

Call_stmtFcntl_setlk(fd)

Func_declFcntl_setlk


Expr_stmt=

Var_declfilp

call_declFget(fd)

cmpd_stmtUse filp

Control Flow (Interprocedural)

Func_declSys_fcntl


Expr_stmt=

Var_declfilp

call_declFget(fd)

Expr_stmt=

Var_declerr


call_decldo_fcntl

Func_declDo_fcntl

Expr_stmt=

Var_declerr




Expr_stmt=

Var_declfilp

call_declFget(fd)

cmpd_stmtUse filp

Control Flow (Intraprocedural)

Func_declSys_fcntl


Expr_stmt=

Var_declfilp

call_declFget(fd)

Expr_stmt=

Var_declerr


call_decldo_fcntl

Func_declDo_fcntl

Expr_stmt=

Var_declerr




Expr_stmt=

Var_declfilp

call_declFget(fd)

cmpd_stmtUse filp

Data Flow

Func_declSys_fcntl


Expr_stmt=

Var_declfilp

call_declFget(fd)

Expr_stmt=

Var_declerr


call_decldo_fcntl

Func_declDo_fcntl

Expr_stmt=

Var_declerr




Expr_stmt=

Var_declfilp

call_declFget(fd)

cmpd_stmtUse filp

Def-Use

Func_declSys_fcntl


Expr_stmt=

Var_declfilp

call_declFget(fd)

Expr_stmt=

Var_declerr


call_decldo_fcntl

Func_declDo_fcntl

Expr_stmt=

Var_declerr




Expr_stmt=

Var_declfilp

call_declFget(fd)

cmpd_stmtUse filp

Property Models

Finite State Automata– Start Operation – Disable Interrupts– Enable Interrupts – End Operation

Type Constraints– Unchecked type– Checked type– Expect checked type

disable

disableEnd Openable

double_enable double_disableExit w/ disabled

enable

CQUAL Static Analysis

CQUAL is a type-based static analysis tool from UC Berkeley

Enables qualification of types, analogous to const

Enables verification that the type passed to a function is the type expected

Used previously for verification of format string vulnerabilities

– Wagner’s group at UC Berkeley in USENIX Security 2001

CQUAL Principles

Interprocedural control flow– do_fcntl calls fcntl_getlk

Def-Use data flow– Assignments tracked back to def where type is declared– Type inference

Variables have type restrictions– Cannot assign a variable to another of an incompatible type– Cannot send a variable as a parameter to a function unless

its type is compatible

CQUAL Approach

Initializing Function

Initializing Function

Authorizing Function

Controlled Function

Controlled Function

X

unchecked inode i

checked inode i

checkedinode i

require

Identify Declarations

foo(){struct inode * unchecked i; /*declaration*/...security_ops->inode_ops->check(i); /*check*/...map = i->i_mapping; /*local controlled op*/...map->readpage(i); /* function call */}

readpage(struct inode *j) {...} /* subroutine */

Identify Controlled Params

foo(){struct inode * unchecked i; /*declaration*/...security_ops->inode_ops->check(i); /*check*/...map = i->i_mapping; /*local controlled op*/...map->readpage(i); /* function call */}

readpage(struct inode * checked j) {...} /* subroutine */

Create “Checked” Variable

foo(){struct inode * unchecked i; /*declaration*/struct inode * checked i2;...security_ops->inode_ops->check(i); /*check*/i2 = (struct inode * checked) i;...map = i2->i_mapping; /*local controlled op*/...map->readpage(i2); /* function call */}


Verify Local Controlled Ops



Find Assignments to ‘Checked’

foo(){struct inode * unchecked i, * unchecked i3; /*declaration*/struct inode * checked i2, * checked i4;struct dentry * unchecked dentry;...security_ops->inode_ops->check(i); /*check*/i2 = (struct inode * checked) i;i2 = i3; /* unchecked to checked -- fail */i2 = i4; /* checked to checked -- OK */i2 = (struct inode * unchecked) 0xc0000000; /* fail */map->readpage(dentry->d_inode); /* infer checked -- wrong */...}

Verify Interprocedural Paths



Verify Interprocedural Paths

bar(){struct inode * unchecked i; /*declaration*/...map = i->i_mapping; /*local controlled op*/...map->readpage(i); /* function call */}


CQUAL will detect "type error" on 'i'

Find Example 1 Error

sys_fcntl(int fd, ...) {struct file unchecked *filp; ...filp = fget(fd); ...err = security_ops->file_ops->fcntl(filp, ...); ... /* new checked filp2 */do_fcntl(fd, ...); ...}

do_fcntl(int fd, ...) { ...err = fcntl_setlk(fd, ...); ...}

fcntl_setlk(int fd, ...) { ...struct file unchecked *filp; ...filp = fget(fd); /* is this the one checked in sys_fcntl? */

Sensitivity: Flow and Context

Flow-sensitivity– The order of statements in a function matters– CQUAL is not flow-sensitive– Must create new ‘checked’ variable– Must use GCC to verify intraprocedural paths– Must use GCC to find reassignments after ‘checked’

Context-sensitivity– A function is treated differently depending on calling site– CQUAL is not context-sensitive– If two functions call the same descendant must have the

same requirements in CQUAL

CQUAL Postscript

Flow-sensitive CQUAL– Initial performance was not good

Field level data flow– Extensions at UC Berkeley

We switched to new tool (JaBA)– Interprocedural control flow– Intraprocedural control flow (flow-sensitive)– Context-sensitive– Variable and field-level data flow– Replicated analyses of Example 1 and 3 while preventing

false positives of Example 4

Meta-compilation

Compilers– Have program source– Can implement straightforward rules for source

checking– Lack domain semantics of programs

Programmers– Have domain semantics of programs– Need a means to express these semantics such

that they can be checked

Meta-compilation

Model– GCC abstract syntax tree– Compute interprocedural control flow graph– Compute intraprocedural control flow graph

Properties– Finite state automata – Generate extensions from specification

Computation– FSA state transitions are represented by patterns– Find syntactic patterns in code– Build intraprocedural paths with relevant state changes– For each path, compute resultant state transitions

Properties: Meta Language (metal)

{ #include “linux-includes.h” }

sm check_interrupts {

// Variables used in patterns

decl { unsigned } flags;

// Patterns to specify enable/disable fns

pat enable = { sti(); }

| { restore_flags(flags); } ;

pat disable = { cli() };

// States – implicit initial state

is_enabled: disable is_disabled

enable { err(“double enable”); } ;

is_disabled: disable { err(“double disable”); }

| $end of path$ { err(“exiting w/ intr disabled”); }

disable

disableEnd Openable


enable

Example 2 Processing




}

disable

enableend of path

end of path err

Meta-Compilation System

Compile Metal State Machine (SM) with mcc Dynamically link SM into xg++

– Compile-time, command line flag

It is “pushed down” “both paths”– Paths are built and checked against SM

All paths vs one pass (flow-sensitive vs. insensitive)– Prune paths that reach join in same state– Fixed point: loop until reach all possible paths

Prune Paths

disable

enable

Choice of paths doesnot matter, so only oneneeds to be kept

Assertion Checking – Side Effects

{ #include “linux-includes.h” }sm Assert flow-insensitive {

// Match expressionsdecl { any } expr, x, y, z;decl { any_call } any_fcall;decl { any_args } args;

// States: find asserts and detect side effectsstart: { assert(expr); }

{mgk_expr_recurse(expr, in_assert); } ;

in_assert: { any_fcall(args) } { err(“fn call”); }

| { x = y } { err(“assignment”); }| { z++ } { err(“post-increment”); }| { z-- } { err(“post-decrement”); }

xgcc Extension (PLDI 2002)

Match patterns to statements– Identify state transitions

Compute intraprocedural paths– Prune those that cannot matter (no state changes)

Combine intraprocedural paths into complete paths– Analysis instance based on a transition from a start state– Paths are generated for each instance – Assignments result in creating a new instance that is a copy

Checking memory management

unknown

allocation

null not-null

Conditional check on ptrimplying null

Conditional check on ptrimplying not null

freed

free

overwrite

stop

dereference

free, dereference

end path

free,dereference

free

Checking memory management

Intraprocedural control flow– Distinguish between paths with null and non-null pointers

Interprocedural control flow– “Global analysis” done in PLDI by combining intraprocedural paths

Data flow– None, pure syntactic comparison– Assignment does result in replication of state machine for assigned

variable Finds bugs, but does not guarantee absence

– No track of assignment to a structure field– No Aliases

False positives– Syntactic path-sensitivity keeps them moderate

Other Example Analyses

Example 3 – (check fcntl and set_fowner)– If we know the required authorizations for each operation,

we can define the states of these ops– Don’t know this (tedious to specify)– We use a consistency analysis (ACM TISSEC, May 2004)

Example 4 – (distinguish between dentryinode and inode)

– Specify that { inode = dentryinode } links inode state with dentry state

– Note that this does not compute from 1st principles, so manual effort is required to ensure it is correct

xgcc Postscript

Lots of papers on finding bugs using these techniques– Lots of simple errors in code

Other aspects – Automating annotation– Statistical analysis

Coverity, Inc.

GCC Architecture

Compilers for C, C++, Java Consists of a sequence of compilation steps

all of which can be hooked (3.0 and greater) Eventually, has a single representation of all

(gimple) Then converts to Register Transfer

Language (RTL) at which point all typing is lost

MOPS

Aim to provide a ‘sound’ analysis architecture– That is, no false negatives for their model

Program model– Pushdown automata of program

Property model– Finite state automata of security property– Temporal properties

Like xgcc, there is no real data flow analysis Unlike xgcc, language for properties is not defined

Formal Basis

FSA M accepts a language of security property violations B– All operation sequences that obey M violate security property

PDA P accepts all feasible program traces T– Traces are interprocedural combination of intraprocedural control

flow paths– Note that traces are control flow representation

Problem: Decide if any trace violates security property– As whether T B = null– Represented by L(M) L(P) = null– Intersection of PDA and FSA can be computed efficiently– Note that TL(P), so some infeasible traces are in L(P)

Example 2

disable

disableEnd Openable


enable




}

Example 1

check

use

unmediated

assignsys_fcntl(int fd, ...) {struct file *filp; ...filp = fget(fd); ...err = security_ops->file_ops->fcntl(filp, ...); ...do_fcntl(fd, ...); ...

}

do_fcntl(int fd, ...) { ...err = fcntl_setlk(fd, ...); ...

}

fcntl_setlk(int fd, ...) { ...struct file *filp; ...filp = fget(fd); /* is this the one checked in sys_fcntl? */

assign

useuse

Unassigned Use unmediated

assign

check

zero, free

MOPS Distinguishing Features

Modularity– Can create a hierarchy of FSAs– Haven’t seen this used…

Pattern variables– “bound to any expression that satisfies context constraints”– Difference from xgcc patterns?

Modeling– PDA and FSA a combined into a composite PDA that

accepts L(M) L(P) – Can determine all the FSA states that an instruction can be

executed in

Modeling OS for MOPS

Find all kernel variables that affect security– Done manually

Determine the states in the FSA for each– Done manually

Determine transitions between states– Transition in FSA– Automated state space explorer – Execute all paths and create transitions

automatically

Setuid

Variable euid determines privilege Euid can be modified by several functions:

– setuid, seteuid, setreuid, setresuid Value of euid depends on value of other variables on

input to these system calls – ruid, suid– cap_effective, cap_permitted– Are found manually

Transitions indicate system calls that lead to changes in variables

Impact of Soundness

Control flow sound– Combination of PDA and FSA is sound– Context-sensitive– Different than xgcc?

Construction of FSA has manual steps– Identification of variables– Identification of system calls that impact variables– Could these be automated? Data flow…– FSA states are defined manually– Support for finding transitions automatically once we know

the system calls that matter – different than xgcc? Construction of PDA is automated

– Different from xgcc?

Dataflow

Find variables– Manually determine syntactic matches

Definitions Dependencies/States

– Manually determine syntactic dependencies Assignments Parameters Structure members Operations that change state

Values associated with variables– Assume different for each variable; same for struct

Fget(fd) returns a different fd Dentry->inode is same for dentry

Ignore aliases– Could detect in thread; Not usually there

Multiple possible assignments

Classification of Analysis Tools

Specialized checkers (syntactic bugs)– Lint, ITS4, JTest

Annotation checkers (buffer overflows, parse errors)– LCLint, CQual

Automata checkers (temporal bugs – no data flow)– xgcc/metal, MOPS

Control and data flow for custom analyses (temporal ++)– PREfix (C/C++), JaBA (Java)

Predicate Refinement (driver – small program -- verification)– SLAM, MAGIC

More Analysis

Runtime Analysis– Consistency, buffer overflows

Policy Analysis– SELinux

Intrusion Detection– Represent feasible paths through a program

source analysis for security

Documents