1. Aspect Oriented Security Gary McGraw, Ph.D. gem@cigital.com http://www.cigital.com

2. 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

3. The trinity of trouble “As software has become ever more complex, interdependent and interconnected, our reputation as a company has in turn become more vulnerable.” - -- Gates memo (1/02) The trinity of trouble CONNECTIVITY –The Internet is everywhere and everything is on it EXTENSIBILITY –Systems evolve in unexpected ways and are changed on the fly COMPLEXITY –Networked, distributed, mobile code is hard

4. Separation of concerns main () { draw_label(“Haida Art Browser”); m = radio_menu( {“Whale”, “Eagle”, “Dogfish”}); q = button_menu({“Quit”}); while ( ! check_buttons(q) ) { n = check_buttons(m); draw_image(n); } } draw_label (string) { w = calculate_width(string); print(string, WINDOW_PORT); set_x(get_x() + w); } draw_image (img) { w = img.width; h = img.height; do (r = 0; r < h; r++) do (c = 0; c < w; c++) WINDOW[r][c] = img[r][c]; } radio_menu (labels) { i = 0; while (i < labels.size) { radio_button(i); draw_label(labels[i]); set_y(get_y() + RADIO_BUTTON_H); i++; } } draw_circle (x, y, r) { %primitive_oval(x, y, 1, r); } radio_button (n) { draw_circle(get_x(), get_y(), 3); } button_menu (labels) { i = 0; while (i < labels.size) { draw_label(labels[i]); set_y(get_y() + BUTTON_H); i++; } } © 2001 Cigital

5. vm_fault vm_pager_getpages vnode_pager_getpages ffs_getpages ffs_valid ufs_bmap ffs_calc_size … … VM module Aspect-Oriented Programming More than one modularity is possible –Separation of concerns + –Automate security expertise –Apply to legacy code FFS module if (((fs.object->type != OBJT_DEFAULT) && (((fault_flags & VM_FAULT_WIRE_MASK) == 0) || wired)) || (fs.object == fs.first_object)) { if (fs.pindex >= fs.object->size) { unlock_and_deallocate(&fs); return (KERN_PROTECTION_FAILURE); } /* * Allocate a new page for this object/offset pair. */ fs.m = vm_page_alloc(fs.object, fs.pindex, (fs.vp || fs.object->backing_object)? VM_ALLOC_NORMAL: VM_ALLOC_ZERO); if (fs.m == NULL) { unlock_and_deallocate(&fs); VM_WAIT; goto RetryFault; } (((fault_flags & VM_FAULT_WIRE_MASK) == 0) || wired)) { int rv; int reqpage; int ahead, behind; if (fs.first_object->behavior == OBJ_RANDOM) { ahead = 0; behind = 0; } else { behind = (vaddr - fs.entry->start) >> PAGE_SHIFT; if (behind > VM_FAULT_READ_BEHIND) behind = VM_FAULT_READ_BEHIND; : aspect normal_prefetching { pointcut vm_fault_cflow( vm_map_t map ): cflow( calls( int vm_fault( map,.. ))); pointcut ffs_getpages_cflow( vm_object_t obj, vm_page_t* plist, int len, int fpage ): cflow( calls( int ffs_getpages( obj, plist, len, fpage ))); before( vm_map_t map, vm_object_t obj, vm_page_t* plist, int len, int fpage ): calls( int vnode_pager_getpages( obj, plist, len, fpage )) && vm_fault_cflow( map ) { if ( obj->declared_behaviour == NORMAL ) { vm_map_lock( map ); plan_and_alloc_normal( obj, plist, len, fpage ); vm_map_unlock( map ); } after( vm_object_t obj, vm_page_t* plist, int len, int fpage, int valid ): calls( valid ffs_valid(..) ) && ffs_getpages_cflow( obj, plist, len, fpage ) { if ( valid ) dealloc_all_prefetch_pages( obj, plist, len, fpage ); } after( vm_object_t obj, vm_page_t* plist, int len, int fpage, int error, int reqblkno ): calls( error ufs_bmap( struct vnode*, reqblkno,..) ) && ffs_getpages_cflow( obj, plist, len, fpage ) { if ( error || (reqblkno == -1) ) dealloc_all_prefetch_pages( obj, plist, len, fpage ); aspect sequential_prefetching { pointcut vm_fault_cflow( vm_map_t map ): cflow( calls( int vm_fault( map,.. ))); pointcut ffs_read_cflow( struct vnode* vp, struct uio* io_inf, int size, struct buff** bpp ): cflow( calls( int ffs_read( vp, io_inf, size, bpp ))); before( vm_map_t map, vm_object_t obj, vm_page_t* plist, int len, int fpage ): calls( int vnode_pager_getpages( obj, plist, len, fpage )) && vm_fault_cflow( map ) { if ( obj->declared_behaviour == SEQUENTIAL ) { vm_map_lock( map ); plan_and_alloc_sequential( obj, plist, len, fpage ); vm_map_unlock( map ); } around( vm_object_t obj, vm_page_t* plist, int len, int fpage ): calls( int ffs_getpages( obj, plist, len, fpage )) { if ( obj->behaviour == SEQUENTIAL ) { struct vnode* vp = obj->handle; struct uio* io_inf = io_prep( plist[fpage]->pindex, MAXBSIZE, curproc ); int error = ffs_read( vp, io_inf, MAXBSIZE, curproc->p_ucred ); return cleanup_after_read( error, obj, plist, len, fpage ); } else proceed; } after( struct uio* io_info, int size, struct buf** bpp ): else firstpindex = fs.first_pindex - 2*(VM_FAULT_READ_BEHIND + VM_FAULT_READ_AHEAD + 1); for(tmppindex = fs.first_pindex - 1; tmppindex >= firstpindex; --tmppindex) { vm_page_t mt; mt = vm_page_lookup( fs.first_object, tmppindex); if (mt == NULL || (mt->valid != VM_PAGE_BITS_ALL)) break; if (mt->busy || (mt->flags & (PG_BUSY | PG_FICTITIOUS)) || mt->hold_count || mt->wire_count) continue; if (mt->dirty == 0) vm_page_test_dirty(mt); if (mt->dirty) { vm_page_protect(mt, VM_PROT_NONE); vm_page_deactivate(mt); } else { vm_page_cache(mt); } ahead += behind; behind = 0; } if (fs.first_object->behavior == OBJ_RANDOM) { ahead = 0; behind = 0; } else { behind = (vaddr - fs.entry->start) >> PAGE_SHIFT; if (behind > VM_FAULT_READ_BEHIND) behind = VM_FAULT_READ_BEHIND; ahead = ((fs.entry->end - vaddr) >> PAGE_SHIFT) - 1; if (ahead > VM_FAULT_READ_AHEAD) ahead = VM_FAULT_READ_AHEAD; : © 2001 Cigital

6. Security problems and features IMPLEMENTATION Buffer overflow –String format –One-stage attacks Race conditions –TOCTOU Unsafe environment variables Unsafe system calls –System() ARCHITECTURE? Misuse of cryptography Privileged block protection Survivability mechanisms Type safety properties Secure auditing services Access control

7. The Cigital Aspect Weaver Research prototype, experiments, and metrics

8. Architecture

9. State of play Build Integration –weaving integrates seamlessly into development environment Infrastructure for future aspects Prototype aspect language and weaver –syntax and semantics similar to AspectJ –expressiveness well understood –requirements/design considerations for further improvements scoped Prototype “low-level” aspects Prototype “mid-level” aspects Research “high-level” aspects

10. Implementation level aspects Experiments and metrics

11. Aspect: Format string b.o. New Mexico results –Wu-ftpd 2.6.0 (redhat) –Format string buffer overflow Crosscut program modules Global decision Local fixes

12. Measuring results (format string) Validation metrics –Successfully prevents the usage of anomalous format strings. –Small performance penalty. –Target functions with format strings are relatively few. Code metrics (experiment) –LOC (ftpd.c) Raw 7292 (187096k) PPr 11894 (258745k) AOP 7195 (182098k) –SPREAD 1 aspect  2 calls protected –PORTABILITY highly portable for vsnprintf() calls –PERFORMANCE No measured hit

13. Aspect: TOCTOU 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.

14. Measuring results (TOCTOU) Validation metrics –Safely changes the order in which the file system functions are called. –Prototype protects over 50 C Standard and basic UNIX file manipulation functions. –Drawback: May eventually use up all the available file descriptors in current implementation. Code metrics (experiment) –LOC (ftpd.c) Raw 7516 (192821k) PPr 16253 (178974k) AOP 6321 (144872k) –SPREAD 1 aspect  85 calls wrapped –PORTABILITY highly portable –PERFORMANCE No measured hit

15. Aspect: Input sanitation 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! –Enforce standard input policy rules across an organization. Example: The classic phf CGI-bin problem

16. Measuring results (input cleaner) Validation metrics –Input sanitation aspect properly cleans input stream using a white list approach. –Replaces meta characters in the FTPD input channel. –Problem: new aspects must be written from scratch to account for different input schemes. Code metrics (experiment) –LOC (ftpd.c) Raw 7516 (192821k) PPr 16253 (178974k) AOP 6082 (143006k) –SPREAD 1 aspect  1 function fixed –PORTABILITY Application specific –PERFORMANCE No measured hit

17. Aspect: weaving in canaries (b.o.) Crispin’s Stackguard feature dynamically protects against some forms of stack smashing attacks –Canary guards the return address Microsoft’s /GS feature does similar things

18. What the weaver does #define CANARY (*((int *)"\0\0\n\n")) aspect bufferAspect { bufferProtect { 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); }

19. Measuring results (canary) Validation metrics –Canary placed around all potentially vulnerable buffers (code dependent) –Scalability depends on the number of vulnerable places in the target. Tiny runtime hit. –Attack coverage: only naïve buffer overflow attacks. Two stage and greater attacks not handled. Code metrics (experiment) –LOC (ftpd.c) Raw 7516 (192821k) PPr 16253 (178974k) AOP 23056 (160121k) –SPREAD 1 aspect  165 buffers protected –PORTABILITY highly portable –PERFORMANCE No measured hit

20. Toward design level aspects Prototypes and metrics

21. Moving up the food chain IMPLEMENTATION –Low level flaws are important, but are overemphasized –ITS4: www.cigital.com/its4www.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?

22. On bricks and walls Software security is about implementation AND architecture Implementation analysis –Dig into the code –Focus in on areas of high risk (guided analysis) Architectural analysis –Identify and rank risks –Use attack patterns –System-wide view DARPA-hard research –Design for security –Getting past simple flaws –Higher-level analysis Scanners (even the basic AOP tool) look for flaws at the “brick” level e.g., Buffer overflows strncpy ()

23. 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

24. Measuring results (crypto) Validation metrics –Data channels and command channel for wu- ftpd protected. –Scalability is questionable. Key management problems. (prototype uses static keys) –Standard attacks (sniffer- based) are thwarted. Code metrics (experiment) –LOC (ftpd.c) Raw 7516 (192821k) PPr 16253 (178974k) AOP 9402 (276072k) –SPREAD 3 functions in aspect  4 places protected –PORTABILITY Incomplete. The current prototype has issues. –PERFORMANCE (  ) File transfer Key management (!) File sizeNormalCrypto 1.7Mb4.02sec25.91sec 4.9Mb7.81sec1:13sec 20.1Mb32.29sec4:59sec

25. Aspect: Privilege protection Problem –Code responsible for the elevation of privilege is tricky to write. –Many programs require elevation of privilege in diverse locations. SUID/GUID Approach –Use tags to specify locations where privilege must be raised. –Weave in facility to protect against various potential exploits of the raised privilege in the critical block. Example:FTPD setuid/signal exploit

26. What the weaver does aspect Privilege_Aspect { sigset_t saved, blocked; labelRange { before { sigprocmask( SIG_BLOCK, &blocked, &saved ); } after { sigprocmask( SIG_SETMASK, &saved, 0 ); }

27. Measuring results (privilege) Validation metrics –Protects a block of code against signals. –Issue: Currently requires that the programmer tag critical areas. Code metrics (experiment) –LOC (ftpd.c) Raw 7516 (192821k) PPr 16253 (178974k) AOP 6171 (144235k) –SPREAD 1 aspect  57 signal calls wrapped –PORTABILITY highly portable (works on signal calls) –PERFORMANCE No measured hit

28. Concrete tasks (work continues) Identify secure design features that system designers can and will use Extend current AOP framework to enable weaving of secure design solutions Develop secure design aspects Protecting channels/secure access control/secure logging Validate effectiveness of approach experimentally Work on more abstract secure design aspects

29. Are we there yet? Moving the edge

30. Aspect: Survivability Problem –Programs may need to run a block of code whose execution time may be unreasonable. –The implementation of this code may not be easily modified to allow for simple stoppage. Approach –An aspect which saves the state of a program prior to entering an unsafe block of code. –Should a woven block take too long to complete, the program will cease execution and exit the block unsuccessfully. Example:FTPD directory name DOS attack

31. Security and Fault Tolerance How can AOP help with fault tolerance? Maintain copies of the program state that can be restored upon detection of corruption. Couple with the ability to roll-back the file system state. Add limited ability to handle exceptions in order to help programmers deal with these problems.

32. Run-time Type Information How can we build a better Buffer Overflow aspect? Proper variable bounds checking requires Run- time Type Information (RTTI) By weaving in RTTI labels, we may be able to disallow inappropriate use of memory blocks in C Language as well Similarities to Cyclone, Cqual, Crispin’s work

33. Summary AOP provides uniform framework for automatically building secure software Automatic knowledge application –Separation of concerns –Security aspects are reusable and extensible –Implementation and mid-level aspects work in practice How far can we go? –Type safety –Security fault tolerance For more information: –gem@cigital.com –fhill@cigital.com