Secure application development with AOP Nils Durner - - PowerPoint PPT Presentation

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 stores1 – operators2

1AspeCt-oriented C: global variables only 2AspectC ++ 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

Validating heap pointers with sbrk()

• Depending on the malloc() implementation, brk() and sbrk() are

used as actual allocators – Linux: MALLOC MMAP THRESHOLD = 128KB

• Most allocations are within this brk region
• sbrk(0) and mallinfo() can be used to determine the region’s size
• Can be used to

– avoid expensive checks of /proc/self/maps – decrease the memory overhead of an allocation tracker

31

Validating stack pointers

• Determine the stack base address3

– NtCurrentTeb() (Windows NT) – libc stack end (glibc) – address of the page containing a variable in the current stack frame (Windows) – pthread attr getstack() (pthreads) – pthread get stackaddr np() (pthreads, MacOS X) – unw get reg(. . . , UNW REG SP, . . . ) (libunwind)

3see also http://cvs.savannah.gnu.org/viewvc/*checkout*/guile/guile-core/libguile/threads.c?

root=guile&revision=1.84.2.10&content-type=text%2Fplain

32

Validating stack pointers

• Determine the top of the stack

– x86 register EBP – the address of a variable in the current stack frame

• Check whether the pointer is between the top and the base of the

stack

33

Validating pointers to the data and code segments

• The pointer may point to a block in a page that

– the x86 register DS points to (data segment) – contains the current function (code segment)

• Use OS interfaces to determine executability

– VirtualQuery() – /proc/self/maps ∗ Result can be cached since code and data segments are not dynamic

34

Summary: validating pointers

• Record all memory allocations and deallocations
• In memory accessing functions, check whether the pointer is within

a block which

• 1. . . . is on the stack
• 2. . . . was allocated using brk()/sbrk()
• 3. . . . is located inside the code or data segment
• 4. . . . is on the heap
• In memory modifying functions, check that the block is actually

large enough

35

Preventing write access across stack boundaries4

• Keep shadow copy of the function call stack

– Save beginning (register esp) and end (register ebp) of each stack frame

• Check the write range in an around-advice for each unsafe function

– Deny write access to regions between the end of a stack frame (ebp) and the beginning of the next frame (esp) – Only allow write access until the end of the stack frame (ebp)

4on x86 36

Preventing buffer overflow escalation

• [1, libunwind] can be used to retrieve function call stacks
• Overwritten return addresses result in different call stacks which

can be observed using libunwind

• Solution: compare call stacks before and after the execution of an

unsafe function

• Does not work with compiler option -fomit-frame-pointer (or -O3)

37

Micro-benchmark: checking 10M buffers

200 400 600 800 1000 1200 1400 s b r k ( ) s t a c k s t a t i c m e m

• r

y t r a c k i n g / 1 2 K m e m

• r

y t r a c k i n g / 2 K msecs

38

Micro-benchmark: checking 10M buffers

5000 10000 15000 20000 25000 30000 35000 40000 s b r k ( ) s t a c k s t a t i c m e m

• r

y t r a c k i n g / 1 2 K m e m

• r

y t r a c k i n g / 2 K V i r t u a l Q u e r y ( ) / p r

• c

/ s e l f / m a p s msecs

39

Benchmark: libmicrohttpd

0.5 1 1.5 2 2.5 3 3.5 4 w i t h c h e c k s w i t h

• u

t c h e c k s MB/sec

40

Limitations

• Direct memory access cannot be checked in ACC 0.8

int i, a[5]; for (i = 0; i < 10000) a[i] = 0;

• Writes across object boundaries can only be detected for heap

locations tracked through aspects or hooks for malloc(), free(), . . .

int a[2], b; a[2] = 42;

• Depending on the weaver implementation, join-points in 3rd party

libraries cannot be instrumented

41

Dealing with invalid pointers

• abort(), exit()
• spawn helper process, terminate and get started again by the helper
• abort transaction
• do not carry out the offending function call

42

Future work

• Check operands of operators for

– invalid pointers – integer overflows

• “flightrecorder”

– debugging – honeypots

43

Questions?

→ /http://ndurner.de/crisp-aop

44

45

46

Introduction to honeypots

• “A honeypot is a resource who’s value is in being probed, attacked
• r compromised” [10, Honeynet project, 2003]
• Tasks fullfilled by honeypots ([15, Spitzner, 2003]):

– Production ∗ Attack prevention: slows down the attacker (”sticky honeypot”) ∗ Attack detection: allows to find weak spots in prevention systems ∗ Attack response: other than real production systems, honeypots can be taken offline for full analysis.

47

Introduction to honeypots

• Tasks fullfilled by honeypots (contd.):

– Research ∗ Study trends in attacker activity ∗ Early warning and prediction

48

Types of honeypots

[15, Spitzner, 2003] classifies honeypots in two types:

• Low-interaction honeypots

– Limited interaction with the attacker – Usually emulate parts of operating systems and services – Easy deployment and maintenance – Minimize risks – Log information is limited – Designed to capture known activity – Easy to detect

49

Types of honeypots

• High-interaction honeypots

– “Nothing is emulated, we give attackers the real thing.” – Extensive amounts of information can be captured – Make no asumption about how an attacker will behave – More complex to deploy and maintain – Increased risk of abuse

50

Applications of AOP for honeypots

• Adds some of the strengths of low-interaction honeypots to high-

interaction honeypots – Sophisticated logging of detailed information – Improved security

• Buffer validation

– . . . protects honeypots against buffer overflows – . . . helps to find currently unknown security issues

51

Applications of AOP for honeypots

• Restriction or redirection of access to

– files – networks

• Recording function calls allows to

– log attack vectors – detect altered control flows by comparing the recorded information with information gathered by stack based observers such as [1, libunwind].

52

Classified data

• Any data should be considered classified by default

– Database content – File content

• Every copied or derived data is still classified
• Classified data may not be passed to untrusted items without

selective declassification

53

Tracking the data flow

• Each object gets security properties assigned on creation

– Origin ∗ “External” · “File” · “Network” · . . . ∗ “Internal” – Classification – Trustworthyness – . . .

54

Tracking the data flow

• Copies and derived objects retain security properties
• around-advices check (and probably alleviate)

– untrustworthy parameters being passed to critical functions – classified parameters being passed to untrustworthy items

55

References

[1] libunwind. http://www.nongnu.org/libunwind/index.html. [2] Chris Anley. Advanced sql injection in sql server applications. http://www. nextgenss.com/papers/advanced_sql_injection.pdf, 2002. [3] Frank Piessens Bart De Win, Wouter Joosen. Aosd & security: a practical

• assessment. Technical report, Katholieke Universiteit Leuven, 2003.

[4] CERT Coordination Center. Cert advisory ca-1996-03 vulnerability in kerberos 4 key server. http://www.cert.org/advisories/CA-1996-03.html, 1996. [5] CERT Coordination Center. Cert advisory ca-2000-02 malicious html tags embedded in client web requests. http://www.cert.org/advisories/ CA-2000-02.html, 2000.

56

[6] Microsoft Corporation. Virtualquery function. http://msdn2.microsoft. com/en-us/library/aa366902(VS.85).aspx. [7] Crispin Cowan, Matt Barringer, Steve Beattie, Greg Kroah-Hartman, Mike Frantzen, and Jamie Lokier. FormatGuard: Automatic protection from printf format string vulnerabilities. pages 191–200, 2001. [8] Ian Goldberg and David Wagner. Randomness and the netscape browser. http://www.ddj.com/windows/184409807, 1996. [9] Anurag Mendhekar Chris Maeda Cristina Videira Lopes Jean- Marc Loingtier John Irwin Gregor Kiczales, John Lamping. Aspect-oriented programming. http://www.cs.ubc.ca/~gregor/papers/ kiczales-ECOOP1997-AOP.pdf, 1997. [10] The honeynet project. Know your enemy: Defining virtual honeynets. http: //www.honeynet.org/papers/virtual/, 2003.

57

[11] SANS Institute. Sans top-20 2007 security risks. http://www.sans.org/ top20/, 2007. [12] J.T. Bloch J. Viega and P. Chandra. Applying aspect-oriented programming to security. Cutter IT Journal, 14(2):31–39, 2001. [13] Daniel Quinlan. proc - process information pseudo-filesystem. http://man. linuxquestions.org/?query=proc&type=2&section=5, 1995. [14] Alan Schwartz Simson Garfinkel, Gene Spafford. Secure programming techniques, part 4. http://www.onlamp.com/pub/a/onlamp/excerpt/ PUIS3_chap16/index4.html?page=1, 2003. [15] Lance Spitzner. Honeypots. http://www.spitzner.net/honeypots.html, 2003. [16] The AspeCt C team. Acc compiler tools. http://research.msrg. utoronto.ca/ACC/Adapter, 2007. [Online; accessed 29-March-2008].

58

[17] Calvin Lin Walter Chang. Guarding programs against attacks with dynamic data flow analysis. http://domino.watson.ibm.com/acas/w3www_acas. nsf/images/conf06/$FILE/calvin.pdf, 2006. [18] Peter Watkins. Apache web server 2.2: htpasswd predictable salt weakness. http://www.securityfocus.com/archive/1/488123/30/30/ threaded, 2008. [19] Wikipedia. Aspect-oriented programming — wikipedia, the free encyclopedia. http://en.wikipedia.org/w/index.php?title=Aspect-oriented_ programming&oldid=200799238#Implementations, 2008. [Online; accessed 29-March-2008].

59