Aspectizing Security Concerns

hipshorseheadsΔιακομιστές

17 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

77 εμφανίσεις

Aspectizing Security Concerns

Ivan Minevskiy


April 22, 2005

2

Motivation and Goals



Security checks can be tangled with
applications and are hard to modularize



Goals
:


investigate existing approaches to security
augmentation


investigate how AOP techniques can be applied to
modularize security concerns



/

19

3

Overview


Existing methods that were investigated:



Runtime wrappers with security functionality for off
-
the
-
shelf component




Static dataflow
-
based techniques for detecting
untrusted values reaching security
-
critical operations




Runtime access control models:



stack inspection


history
-
based



Race conditions detection in filesystem accesses


Java Security Architecture




This presentation will cover the first three


/

19

4

Generic Software Wrappers

(for C)


A GSW is a state machine



at run
-
rime, listens for specified events



if it "hears" an event, may take some actions such as
augmenting, transforming, or denying it


does not impose context
-
switch overhead




efficient


executed in kernel space




protected



Wrapper Definition Language



a superset of
C



has domain
-
specific language constructs




Multiple wrappers can concurrently wrap a single
process


/

19

5

Aspectizing GSW


The GSW state machine is similar to aspects
“listening” for events at their join points




Observe and modify the data passing through
component interfaces with an around advice
attached to component’s interface methods




Aspects


have small performance overhead



are written in a high
-
level language (e.g.,
AspectJ
)



Can have several advices affecting the same join
point


can control the precedence of advices


/

19

6

Overview


Existing methods that were investigated:



Runtime wrappers with security functionality for
off
-
the
-
shelf component




Static dataflow
-
based techniques for detecting
untrusted values reaching security
-
critical
operations




Runtime access control models:


stack inspection


history
-
based


/

19

7

Securing Dataflow




Given


a list of untrusted sources and sinks


a list of security
-
critical operations



Internal dataflow analysis makes sure that


untrusted input is sanitized before being used


sensitive data is not released without authorization



/

19

8

Example: a Dataflow Exploit

Cross
-
site scripting is a security problem in web
-
applications



/

19

The problem could have been avoided if A
sanitized data coming from untrusted sources


9

Securing Dataflow: Type Qualifiers



Extend type system with two extra
type
qualifiers

:
checked


and
unchecked



For any type T

checked T

is a
subtype

of

unchecked T



Example:

/

19

void foo(unchecked int);

checked int x;

foo(x);



(a) Typechecks

void bar(checked int);

unchecked int y;

bar(y);




(b) Type error

10

Securing Dataflow: Type Inference



All objects received from untrusted sources
are initialized as
unchecked



Security checks (
e.g. string sanitization
)
change the qualified type to
checked



Type inference and analysis engine reports a
type violation

if an unchecked value might
reach a
critical operation

/

19

11

Aspectizing Dataflow Analysis



AspectJ pointcut can only reason about


instant properties (e.g., method name), and


flow of control (e.g.,
cflow
)



No standard pointcuts to address dataflow




New kind of pointcut:
dflow

[
Masuhara

at al., 2003
]


identifies join points based on the origins of data

/

19

12

Example: Sanitizing with
dflow



replace

out.print(s)

with

out.print(quote(s))

when


generating responses, and




/

19

the argument comes from the browser’s request



dflow

tracks back

to “indirect” origins

across modules

dflow

can be

c
ombined

with the
other

pointcuts


Diagram from
www.graco.c.u
-
tokyo.ac.jp/~masuhara/papers/aplas2003
-
talk.pdf

13

Overview


Existing methods that were investigated:



Runtime wrappers with security functionality for
off
-
the
-
shelf component




Static dataflow
-
based techniques for detecting
untrusted values reaching security
-
critical
operations




Runtime access control models:


stack inspection


history
-
based


/

19

14

Access Control:
Stack Inspection



Each

piece

of

code

(POC)

is

assigned

a

static

upper

bound

on

permissions



At

run
-
time,

the

permissions

of

a

POC

are

the

intersection

of

all

the

static

permissions

of

the

POCs

on

the

stack




Limitation
:

remains

blind

to

any

interaction

not

recorded

on

the

current

execution

stack
.

Example
:

1.
A

calls

B


2.
B

returns

leaving

the

system

in

an

unexpected

state

3.
A

calls

C

and

this

call

depends

on

the

earlier

call

to

B




Used

by

JVM

and

CLR

/

19

15

Access Control:
History
-
based



Each

piece

of

code

(POC)

is

assigned

a

static

upper

bound

on

permissions

(as

with

stack
-
based)



The

run
-
time

rights

of

a

POC

are

determined

by

examining

the

attributes

of

any

POC

that

have

run
:


POCs

on

the

stack

and

also



POCs

that

have

been

called

and

returned




Current

rights

when

a

method

terminates

are

lower

than

or

equal

to

their

value

before

the

method

call




Next
:

high
-
level

language

constructs

Grant

and

Accept

/

19

16

Access Control:
History
-
based

(2)

Grant (P) {B} :

When running after less trusted code








(
e.g., when called by that code
):

1.
save current rights

2.
amplify current rights with permissions P

3.
perform sensitive operations (B)

4.
current rights = saved values


final values



Accept (P) {B} :

When running less trusted code








(
e.g., when calling less trusted methods
)

1.
save current rights

2.
perform untrusted operations (B)

3.
if (B completes normally)


current rights += saved


P


else


current rights are not modified

/

19

17

Aspectizing Access Control


To

emulate

a

history

based

access

control

model



Create

3

types

of

around

advices



default



grant



accept



Pointcuts

match

calls

which

should

be

accepted

or

granted




Unmatched

calls

are

processed

in

a

default

way


current

rights

after

the

call

=

saved

values




final

values




Current

and

static

rights

can

be

stored

in

an

inter
-
type

ThreadLocal

object


/

19

18

Proposed Validation



Introduce

several

aspects

into

an

old

version

of

a

security
-
critical

Java

application



Roll

them

forward

into

their

subsequent

incarnations

in

the

next

versions

of

the

application




Helps

to

better

understand

how

an

AO

implementation

would

have

evolved

with

the

application



Limitation
:

focuses

only

on

the

evolution

of

specific

concerns

in

isolation



Proposed

application
:

Apache

Tomcat

web
-
server

/

19

19

Conclusion


Investigated existing approaches to security
augmentation



Runtime wrappers with security functionality for


off
-
the
-
shelf component




Static dataflow
-
based techniques for detecting untrusted
values reaching security
-
critical operations




Runtime access control models:


stack inspection


history
-
based



Race conditions detection in filesystem accesses


Java Security Architecture



Investigated how AOP techniques can be applied to
modularize security concerns


/

19