Secure Programming. CSC 482/582: Computer Security Slide #1

Transcription

1 Secure Programming CSC 482/582: Computer Security Slide #1

2 Topics 1. Robust and Secure Programming 2. Race Conditions and TOCTOU vulnerabilities 3. Error Handling 4. Securing Secrets in Memory 5. Secure Programming References CSC 482/582: Computer Security Slide #2

3 Robust Code Principles Paranoia Assume all input is evil. Check all function calls for errors or exceptions. Check all input to ensure it is not malformed. Assumption of Stupidity Don t assume coders or users read documentation. All functions should handle incorrect, missing, and malformed parameters. CSC 482/582: Computer Security Slide #3

4 Robust Code Principles Avoid Dangerous Implements Any data that code expects to remain consistent is a dangerous implement. Assume any data controlled by caller can change unexpectedly. Can Happen Object creation can fail due to lack of memory. Closing a file can fail when a USB drive is removed. Command line arguments can be NULL. CSC 482/582: Computer Security Slide #4

5 Assumptions Know what assumptions your code makes Assumptions that certain properties are true. Text is UTF-8 encoded text Data is properly formatted XHTML Temperature is an integer between 32 and 212. Assumptions that other properties are false. Input is never longer than X bytes Input is never zero bytes. Input is never a negative number. Then check that those assumptions are true. CSC 482/582: Computer Security Slide #5

6 Secure Code Secure Code is Robust Code that Satisfies (implicit or explicit) security properties. Implicit security properties often include Absence of well known types of vulnerabilities. Protection of CIA properties in certain states. Explicit security properties Ensure developer knows what to protect. Ensure user knows that assets are protected. CSC 482/582: Computer Security Slide #6

7 Who do you trust? Client users example: encryption key embedded in client Operating system example: dynamicly loaded libraries Calling program example: environment variables Vendor example: Borland Interbase backdoor , only discovered when program made open source CSC 482/582: Computer Security Slide #7

8 Trust is Transitive If you call another program, you are trusting the entities that it trusts. Processes you spawn run with your privileges. Did you run the program you think you did? PATH and IFS environment variables What input format does it use? Shell escapes in editors and mailers What output does it send you? CSC 482/582: Computer Security Slide #8

9 What is a Race Condition? Incorrect behavior arising from unexpected dependency on relative timing of events. Timing of events on multitasking system depends on system load. Events generally happen in the expected order. On multitasking system, processes can be interrupted between any two instructions. Private resources (memory) are protected. Shared resources (filesystem, network) can be modified by interrupting process. CSC 482/582: Computer Security Slide #9

10 Java Servlet Hit Counter // Example from BSS, pp public class Counter extends HttpServlet { int count = 0; public void doget(httpservletrequest in, HttpServletResponse out) throws ServletException, IOException { out.setcontenttype("text/plain"); Printwriter p = out.getwriter(); count++; p.println(count + " hits so far!"); } } CSC 482/582: Computer Security Slide #10

11 Analysis of Hit Counter Assumes variable count does not change between incrementing and printing. What if users A + B hit page at approximately the same time? A is first, count = 1 B is second, before println occurs, count = 2 A sees 2 hits so far B sees 2 hits so far CSC 482/582: Computer Security Slide #11

12 Window of Vulnerability Period of time when violating assumption about order of events will produce incorrect behavior. Generally <1s under ordinary conditions. What if web site is popular? What if attacker can send many requests? CSC 482/582: Computer Security Slide #12

13 Window of Vulnerability 1. Attacker can increase increase size of window by slowing down system. 2. Attacker can increase window size by controlling execution with SIGSTOP/SIGCONT. 3. Attacker can attempt exploit many times. CSC 482/582: Computer Security Slide #13

14 Window of Vulnerability You must reduce the window of vulnerability to zero for system to be secure. CSC 482/582: Computer Security Slide #14

15 Critical Sections Segment of code which may only be executed by one thread at a time. Critical Section executes atomically from viewpoint of other threads. Performance Impact Other threads must wait for thread in critical section to finish executing. Limit critical section size. CSC 482/582: Computer Security Slide #15

16 Synchronized Hit Counter // Example from BSS, p. 213 public class Counter extends HttpServlet { int count = 0; public void doget(httpservletrequest in, HttpServletResponse out) throws ServletException, IOException { int mycount; out.setcontenttype("text/plain"); Printwriter p = out.getwriter(); synchronized(this) { mycount = ++count; } p.println(mycount + " hits so far!"); } } CSC 482/582: Computer Security Slide #16

17 Time of Check, Time of Use TOCTOU Security Flaw: 1. Check security of resource. 2. Use resource. What if attacker invalidates security After security check Before use CSC 482/582: Computer Security Slide #17

18 UNIX Example int main( int argc, char *argv[] ) { if(access( argv[1], W_OK ) == 0) { fd = open( argv[1], O_WRONLY ); writefile(fd); } else { perror( Permission denied.\n ); exit(1); } } CSC 482/582: Computer Security Slide #18

19 Analysis Window of Vulnerability Time between access() and open() Exploit: rebind filename Give filename as argument: /tmp/x After access(), delete /tmp/x create link named /tmp/x pointing at root-owned file like /etc/passwd, /.rhosts Example: xterm log file race condition CSC 482/582: Computer Security Slide #19

20 ex: passwd [Bishop, 1996] passwd: allows user-specified passwd file Normal functioning 1. opens passwd file + reads user entry; closes 2. creates + opens temp file ptmp in same directory 3. opens passwd file again, then copies contents to ptmp with user changes 4. closes both passwd and ptmp files; renames ptmp to passwd CSC 482/582: Computer Security Slide #20

21 ex: passwd (cont.) Attacker Goal: rewrite /user/.rhosts contents: localhost attacker ::::: exploit: rlogin l user localhost Plan of Attack Create exploit.rhosts file in attack directory Specify passwd file to be in attack directory steps 1 + 3: directory containing passwd file is attack directory steps 2 + 4: directory containing passwd:/user CSC 482/582: Computer Security Slide #21

22 passwd attack setup mkdir attackdir echo localhost attacker ::::: > attack/.rhosts # want link to point to attackdir for step 1 ln s attackdir link # specify password file using symlink dir passwd link/.rhosts CSC 482/582: Computer Security Slide #22

23 passwd: step by step 1. passwd program opens + reads link/.rhosts actual file: attackdir/.rhosts 2. Attacker changes link to point to /user 3. passwd program creates + opens link/ptmp actual file: /user/ptmp 4. Attacker changes link to point to attackdir CSC 482/582: Computer Security Slide #23

24 passwd: step by step 1. passwd program opens link/.rhosts actual file: attackdir/.rhosts 2. passwd program copies contents to ptmp actual file: /user/ptmp 3. Attacker changes link to point to /user CSC 482/582: Computer Security Slide #24

25 passwd: step by step passwd program closes link/.rhosts + ptmp passwd program renames ptmp to link/.rhosts actual file: /user/.rhosts Password file is now target user s.rhosts We can now rlogin to their account without needing a password CSC 482/582: Computer Security Slide #25

26 UNIX File Binding UNIX provides two forms of naming pathname universal mapping of names to objects indirect: requires parent directories to identify file mapping can be changed by another process file descriptor per-process mapping of identifiers to objects direct: file descriptor points directly to object mapping cannot be changed by another process CSC 482/582: Computer Security Slide #26

27 TOCTOU Binding Flaws Occur with two sequential system calls: both refer to same object by pathname: insecure one binds file descriptor to pathname, other uses that file descriptor: secure one uses file descriptor, other uses pathname: insecure Solution: use calls that use file descriptors Problem: sometimes no alternative to pathnames CSC 482/582: Computer Security Slide #27

28 TOCTOU Binding Flaws Solution: use calls that use file descriptors fchmod() instead of chmod() fchown() instead of chown() fstat() instead of stat() Problem: sometimes no alternative to pathnames link(), unlink(), symlink() mkdir(), rmdir() CSC 482/582: Computer Security Slide #28

29 Security Impact of Error Handling Information leakage Stack traces Database errors Resource leakage Return on error without de-allocation Exceptions bypass de-allocation CSC 482/582: Computer Security Slide #29

30 Error Handling Techniques Return a neutral value: return a value that s known to be harmless, i.e. a negative number, zero, or. Substitute the next piece of data: continue reading from hardware or file until a valid record is found. Return same answer as last time: don t keep reading; instead return the last valid answer. Substitute closest legal value: if velocity has a range of , show a 0 when backing up. Log a warning message: Write a warning to a log, then continue on, perhaps using one of the other techniques. CSC 482/582: Computer Security Slide #30

31 Error Handling Techniques Terminate program: Terminate program execution. Return an error code: Report error by Setting the value of a status variable (errno) Return status as the function s return value Throw an exception Multiple techniques: Combinations of the above. CSC 482/582: Computer Security Slide #31

32 Return Codes Use function return code to indicate error. Easy to ignore. Simply ignore return code. Error handling logic is mixed with logic processing normal return codes. No universal convention for error codes. Common return code patterns. Negative values when nonnegative expected. NULL values for pointer return codes. CSC 482/582: Computer Security Slide #32

33 Example: character get functions fgetc(), getc(), getchar() read char, return int Use int to represent EOF error code. Incorrect example: return value is declared as a char char buf[bufsiz]; char c; int i = 0; while ( (c = getchar())!= '\n' && c!= EOF ) if (i < BUFSIZ-1) { buf[i++] = c; } buf[i] = '\0'; /* terminate NTBS */ Correct example char buf[bufsiz]; int c; int i = 0; while (((c = getchar())!= '\n') &&!feof(stdin) &&!ferror(stdin)) if (i < BUFSIZ-1) { buf[i++] = c; } buf[i] = '\0'; /* terminate NTBS */ CSC 482/582: Computer Security Slide #33

34 Resource Leaks Resources leak due to early returns Memory Filehandles Example char *getblock(int fd) { char *buf = (char *)malloc(1024); if (!buf) { return NULL; } if (read(fd, buf, 1024)!= 1024) { return NULL; } return buf } CSC 482/582: Computer Security Slide #34

35 Using goto for error handling Problem: need to de-allocate resources on return. Each return is different since Different resources allocated at each point. Solution: single de-allocation point Check if resource is allocated, then De-allocate if it is, and Return with appropriate error code. Why goto? Avoids deep nesting. Improves code readability. Commonly used technique in kernel. CSC 482/582: Computer Security Slide #35

36 Fixed version with goto char *getblock(int fd) { char *buf = (char *)malloc(1024); if (!buf) { goto ERROR; } if (read(fd, buf, 1024)!= 1024) { goto ERROR; } return buf; } ERROR: if (buf) { free(buf); } return NULL; CSC 482/582: Computer Security Slide #36

37 Exceptions Advantages of exceptions Cannot be ignored by not checking for errors. Separate main code from error code. Disadvantages of exceptions Difficult to avoid resource leaks, as exceptions create many implicit control flow paths. Can still ignore exceptions try { // code that can throw an exception } catch (AnException e) { // empty catch block } CSC 482/582: Computer Security Slide #37

38 Checked Exceptions Checked exceptions: Exceptions that the language requires client code to handle. C++, C#: no checked exceptions Java: exceptions that inherit from Exception Unchecked exceptions: Exceptions that can be ignored by client code. C++, C#: all exceptions are unchecked Java: exceptions that inherit from RuntimeException. CSC 482/582: Computer Security Slide #38

39 Exception Guarantees Levels of exception safety for a class. Basic Guarantee No resources are leaked. Strong Guarantee Exceptions leave state exactly as it was before the operation started. No Throw Guarantee Component will handle all exceptions itself. No Exception Safety Component may leak resources and leave object in an inconsistent unusable state. CSC 482/582: Computer Security Slide #39

40 Catch-all Exception Handlers Ensure no information leakage at top level functions. doget(), dopost(), web service entry points protected void dopost(httpservletrequest req, HttpServlet Response res) { try { /* function body */ } catch (Throwable t) { logger.error( Top-level exception caught, t); } } Do not do this in low level code. Need to deal with individual error types separately, instead of ignoring them or handling generically. CSC 482/582: Computer Security Slide #40

41 Destructor De-Allocation Resource Acquisition Is Initialization pattern Resources acquired during initialization of object, before it can be used. Resources are de-allocated by the object s destructor, which occurs even via exceptions. Example file (const char* filename) { file_ = fopen(filename, w+ ); if (!file_) throw std::runtime_error("file open failure"); } ~file() { if (f) { fclose(file_); } } CSC 482/582: Computer Security Slide #41

42 Finally A finally block is executed regardless of whether an exception is caught or not. Example Statement stmt = conn.createstatement(); try { stmt.execute(sqlstring); } finally { } if (stmt!= null ) { stmt.close(); } CSC 482/582: Computer Security Slide #42

43 Secrets in Memory Attackers can obtain secrets from memory Remote exploit: buffer overflow or fmt string Physical attack: direct media access Accidental leakage: core dumps or page files CSC 482/582: Computer Security Slide #43

44 Securing Secrets in Memory Minimize time spent holding secrets. Decrypt data just before use. Overwrite data after use. Share secrets sparingly. Do not store secrets on the client. Erase secrets securely. Explicitly overwrite memory. Prevent unnecessary duplication. CSC 482/582: Computer Security Slide #44

45 Locking Pages in Memory Prevent secrets from paging to disk. Does not prevent suspend or hibernate saving pages. Linux page locking mlock(const void *addr, size_t len) munlock(const void *addr, size_t len) Windows page locking VirtualLock(LPVOID lpaddress, SIZE_T dwsize); VirtualUnlock(LPVOID lpaddress, SIZE_T dwsize); CSC 482/582: Computer Security Slide #45

46 Erasing Secrets Securely Garbage collecting languages Impossible to ensure secrets are erased immediately. Low level languages Compiler can optimize away code that overwrites a buffer if buffer contents are not used later. Use memset_s() if compiler supports C11. Use SecureZeroMemory() in Windows. If neither function is available, use volatile pointers to prevent compiler from optimizing away memory overwrites. Some compilers may still cause problems. CSC 482/582: Computer Security Slide #46

47 Secure Programming References CERT Secure Coding Standards for C, C++, Java, Perl Microsoft Writing Secure Code Secure Programming for UNIX/Linux HOWTO SAFECode Open Web Application Security Project (OWASP) OWASP Code Review Project CSC 482/582: Computer Security Slide #47

48 Secure Programming Books CSC 482/582: Computer Security Slide #48

49 Key Points 1. Validate input from all sources. CLI args, env vars, config files, database, etc. 2. Use the strongest possible technique. 1. Indirect Selection 2. Whitelist 3. Blacklist 3. Reject bad input, don t attempt to fix it. 4. Trust is transitive. 5. Architect for validation: establish trust boundaries, wrap dangerous functions. CSC 482/582: Computer Security Slide #49

50 References 1. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, Steve McConnell, Code Complete, 2/e, Microsoft Press, Gary McGraw, Software Security, Addison-Wesley, PCI Security Standards Council, PCI DSS Requirements and Security Assessment Procedures, v1.2, Mark Graff and Kenneth van Wyk, Secure Coding: Principles & Practices, O Reilly, Michael Howard and David LeBlanc, Writing Secure Code, 2 nd edition, Microsoft Press, Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security, McGraw-Hill Osborne, John Viega, and Gary McGraw, Building Secure Software, Addison- Wesley, David Wheeler, Secure Programming for UNIX and Linux HOWTO, HOWTO/index.html, CSC 482/582: Computer Security Slide #50