Secure application development with AOP Nils Durner <ndurner@web.de> 1
Outline of the talk • Introduction to Aspect Oriented Programming • Examples for uses of AOP for security • AOP & Memory safety • Future work 2
What is AOP? • A new programming paradigm, extends others • Programming paradigms often aid to separate concerns – Procedural languages (C, Pascal): separation in procedures – Object-oriented programming (C++, Java): separation in objects – Model-View-Controller: separation of data and interface concerns – Service-orientation (SOA): separation in logical services 3
What is AOP? • Some concerns defy separation ( cross-cutting concerns ) – Logging – Transactions – Persistence – Security • The primary goal of AOP is separation of cross-cutting concerns [9, Kiczales et al., 1997] 4
How does AOP work? • Code that addresses cross-cutting concerns is separated into individual aspects • Weavers insert that code at specified locations – into source code (AspeCt-oriented C, AspectJ) ∗ can be thought of as “intelligent pre- or postprocessing” – in binary code (AspectJ) • AOP solutions are available for a lot of programming languages (C, C ++ , Java, PHP, . . . ) [19, Wikipedia, 2008] 5
Terminology: Join-point • Join-points are all possible positions in the code where code can be inserted by the weaver – function invocation, entry and/or exit – loads and stores 1 – operators 2 1 AspeCt-oriented C: global variables only 2 AspectC ++ 6
Example: Join-points in C int glob; int foo(int i) { // before function return glob += i; // variable get and set // after function } int main () { int i; glob = 5; // variable set i = 2; foo(i); // function call printf("glob: %u\n", glob); // variable get & function call return 0; } 7
Terminology: Pointcut • A pointcut is a description of a subset of join-points • They tell the weaver where to insert code // calls to foo pointcut call_foo (): call(int foo(int)); // assignments to glob pointcut set_glob (): set(int glob); // all function calls pointcut all_calls (): call($ $(...)); 8
Terminology: Advice • Advices contain the actual code that is to be woven at a join-point • They also tell the weaver how to weave the code – before , after or around a join-point // monitor the global variable glob pointcut set_glob (): set(int glob); after (): set_glob () { printf("glob was modified !\n"); } 9
Terminology: Advice • Code contained in advices – has access to contextual information ∗ function parameters ∗ return values ∗ calling function (name, source file, line number) – can alter the control flow • Advices may use anonymous pointcuts 10
Example: checking malloc() #include <stdio.h> void *around(size_t size): (call($ malloc (...))) && args(size) { void *ptr; if (size > 100000000) { fprintf(stderr , "FATAL: unexpected large allocation in %s::%s()", this ->fileName , this ->targetName); return NULL; } if (! (ptr = proceed ())) { fprintf(stderr , "FATAL: cannot allocate %u bytes in %s::%s()", size , this ->fileName , this ->targetName); } return ptr; } 11
Practical AOP: Java Servlets • Information systems usually check (and sometimes log) access to every function public class ApplicationDetailsServlet extends HttpServlet { protected void doGet( HttpServletRequest req , HttpServletResponse resp) { private static final Logger logger = Logger.getLogger( ApplicationDetailsServlet .class.getName ()); if (! (req.isUserInRole("recruiter") || req.isUserInRole("head of unit"))) { logger.error("Unauthorized access to application details by user " + req.getRemoteUser ()); resp.sendError( HttpServletResponse .SC_UNAUTHORIZED ); return; } logger.info("access to application " + req.getParameter("id")); // functional code } 12
Practical AOP: Java Servlets • . . . or more complicated if certain roles may only see partial data – may involve database lookups • Copy & Paste code 13
Practical AOP: Java Servlets • With AOP, – the overall code can get reduced – allows programmers to focus on a single concern – security constraints etc. can be modified (or disabled) without touching the code ∗ makes it easier to maintain customer specific requirements ∗ useful for demoing, testing and profiling purposes 14
AspeCt-Oriented C • Research project at the University of Toronto • Homepage: http://aspectc.net • Toolchain generates ANSI C • Runs on GNU/Linux and Windows • Integrates with GNU autotools 15
Using Aspect-oriented C • Aspect files are usually denoted with an “.ac” or “.acc” file extension • tacc and accmake replace gcc and make [16, AspeCt C team, 2007] – tacc is an interface for the acc compiler core tacc hello.c hello.acc -o hello 16
Replacement of unsafe functions • Misuse of standard C (libc, CRT) and C++ (libstd++/STL) functions easily causes security problems – Invalid writes (buffer overflows) – Invalid reads (null-pointer dereferences, stale iterators) – File access enforcement only depends on the ∗ user context of the process ∗ abilities of the OS (ACLs, chroot jails) • These shortcomings can be mitigated with AOP – Ultimate goal: a framework that fixes currently unknown security problems [3, de Win et al., 2003] 17
Replacement of the standard PRNG • rand() is cryptographically insecure [14, Garfinkel et al., 2003] • Misuse of PRNGs has caused several security issues in the past – Netscape’s SSL implementation [8, Goldberg et al., 2001] – Kerberos 4 [4, CERT, 1996] – Apache htpasswd [18, Watkins, 2008] • Automatic substitution using ACC is trivial [12, Viega et al., 2001] 18
Replacement of the standard PRNG void __attribute__ (( constructor)) init_rand () { gcry_check_version (NULL); } int around (): call(int rand ()) { int ret; gcry_randomize (( unsigned char *) &ret , sizeof (int), GCRY_STRONG_RANDOM ); return ret; } 19
Secure data flow • Common security problems are because data is handled inappropriately [12, Viega et al., 2001] – Injection vulnerabilities ∗ Format string injection [7, Cowan et al., 2001] ∗ SQL injection [2, Anley, 2001] ∗ Cross-site scripting [5, CERT, 2000] – Information leakage ∗ Lack of end-to-end encryption ∗ Bypass or lack of access control 20
Secure data flow • Common characteristics of these vulnerabilities – Untrustworthy data is used in critical environments – Critical data is passed to untrustworthy items • Solution: dynamic data flow analysis [17, Chang et al., 2006] 21
Untrustworthy data • Every external input is untrustworthy – Values from config files – User input • Every copied or derived data is at least as untrustworthy • Critical functions may not operate on unalleviated untrustworthy data 22
Tagging data in ACC • Security properties can be added to data structures through advices struct { char *filename; } include; introduce (): intype(struct include) { int trusted; } • Does not work with primitive data types 23
Hardening memory manipulating functions • Buffer overflows are a common occurrence on [11, SANS, 2007] • Traditional (low-level) API functions do not check buffers passed as parameters – invalid pointers – buffer size • Idea: check parameters in advices and if invalid, take alternative course of action 24
Hardening memory manipulating functions • Preventing illegal memory access – Check for NULL pointers – Check memory regions – Prevent write access across stack boundaries • Preventing escalation – Verify call stacks obtained by [1][libunwind] 25
Overview of memory types • Heap – brk()’ed (Unix) ∗ Explicit or for smaller blocks obtained with malloc() (Linux) – mmap()’ed (Unix) ∗ Explicit or for bigger blocks obtained by malloc() (Linux) • Stack – Local function variables – memory obtained via alloca() • Data and code segments – Global variables and constants 26
Validating heap pointers • Use OS interfaces to query information about memory regions – VirtualQuery() (Windows) – /proc/self/maps (Linux) – sbrk(0) (Unix) • Record memory allocations and deallocations and check pointers against this list 27
Validating pointers with VirtualQuery() SIZE_T WINAPI VirtualQuery( __in_opt LPCVOID lpAddress , __out PMEMORY_BASIC_INFORMATION lpBuffer , __in SIZE_T dwLength ); • Retrieves information about the page that encloses a specific memory location [6, Microsoft, 2008] – Base pointer – Size – Type – Protection • Slow 28
Validating pointers with /proc/self/maps • Contains addresses and access permissions of currently mapped memory regions [13, Quinlan, 1995] $ cat /proc/self/maps 08048000 -0804 c000 r-xp 00000000 03:01 13496 /bin/cat 0804 c000 -0804 d000 rw -p 00004000 03:01 13496 /bin/cat 0804 d000 -0806 e000 rw -p 0804 d000 00:00 0 [heap] ... • Read access is very slow – Potentially faster: /proc/kpagemap (Linux 2.6.25) 29
Validating heap pointers using an allocation table • Track allocated memory blocks – after -advices for allocator functions (malloc(), free(), mmap(), strdup(), . . . ) – allocation hooks provided by the malloc() implementation 30
Recommend
More recommend
