Aspectizing Security Concerns

1. 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 The problem could have been avoided if A sanitized data coming from untrusted sources / 19

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 ofunchecked T • Example: void bar(checked int); unchecked int y; bar(y); (b) Type error void foo(unchecked int); checked int x; foo(x); (a) Typechecks / 19

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 • replaceout.print(s)without.print(quote(s))when • generating responses, and dflowcan be combinedwith the otherpointcuts • dflow tracks backto “indirect” originsacross modules / 19 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: • A calls B • B returns leaving the system in an unexpected state • 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): • save current rights • amplify current rights with permissions P • perform sensitive operations (B) • current rights = saved values final values Accept (P) {B} :When running less trusted code (e.g., when calling less trusted methods) • save current rights • perform untrusted operations (B) • 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 Tomcatweb-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