1. Error Handling James Walden Northern Kentucky University

2. Topics 1.Error Handling 2.Return Codes 3.Exceptions 4.Logging 5.Survivability

3. CSC 666: Secure Software Engineering Security Impact of Error Handling Information leakage  Stack traces  Database errors Resource leakage  Return on error without de-allocation  Exceptions bypass de-allocation

4. CSC 666: Secure Software Engineering Error Handling Techniques Return a neutral value: return a value that’s known to be harmless, i.e. 0 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 0..100, 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. 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

5. CSC 666: Secure Software Engineering 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.

6. CSC 666: Secure Software Engineering 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 */

7. CSC 666: Secure Software Engineering Example: sprintf() Incorrect example: sprintf returns -1 on error, count can be out of bounds int i; ssize_t count = 0; for (i = 0; i < 9; ++i) { count += sprintf( buf + count, "%02x ", ((u8 *)&slreg_num)[i] ); } count += sprintf(buf + count, "\n"); Correct example uses sprintf_m function f/ CERT managed string library int i; rsize_t count = 0; errno_t err; for (i = 0; i < 9; ++i) { err = sprintf_m( buf + count, "%02x ", &count, ((u8 *)&slreg_num)[i] ); if (err != 0) { /* Handle print error */ } } err = sprintf_m( buf + count, "%02x ", &count, ((u8 *)&slreg_num)[i] ); if (err != 0) { /* Handle print error */ }

8. CSC 666: Secure Software Engineering 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 }

9. CSC 666: Secure Software Engineering Using goto for error handling Problem: 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.

10. CSC 666: Secure Software Engineering 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; }

11. CSC 666: Secure Software Engineering 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 }

12. CSC 666: Secure Software Engineering 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.

13. CSC 666: Secure Software Engineering 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.

14. CSC 666: Secure Software Engineering Exception Safety Example void stack::push(int element) { top++; if( top == size-1 ) { int* buf = new int[size+=32]; if( buf == 0 ) throw “Out of memory”; for(int i = 0; i < top; i++) buf[i] = data[i]; delete [] data; data = buf; } data[top] = element; }

15. CSC 666: Secure Software Engineering 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 seperately, instead of ignoring them or handling genericly.

16. CSC 666: Secure Software Engineering Destructor De-Allocation Resource Aquisition Is Initialization design 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_); } }

17. CSC 666: Secure Software Engineering Finally  Finally block 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(); } }

18. CSC 666: Secure Software Engineering Logging Frameworks Use a standard logging framework.  Provide single consistent view of system.  Facilitate changes, such as logging to a new system or to a database. Examples  syslog()  log4j  java.util.logging

19. CSC 666: Secure Software Engineering Survivability  Survivability: Capability of a system to fulfill its functions even when under attack.  Properties of Survivable Systems:  Resistance to attacks  Recognition of damage from attacks  Recovery of full or essential services  Adaptation to reduce effectiveness of future attacks

20. References 1.David Abrahams, Exception-Safety in Generic Components. Lecture Notes In Computer Science: 69-79, 2000.Exception-Safety in Generic Components 2.Tom Cargill, Exception Handling: A False Sense of Security, C++ Report, Volume 6, Number 9, November-December 1994. 3.CERT, Error Handling, https://www.securecoding.cert.org/confluence/download/attachme nts/3524/error-handling.pdf, 2006. https://www.securecoding.cert.org/confluence/download/attachme nts/3524/error-handling.pdf 4.Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. 5.Robert J. Ellison et. al., Survivability: Protecting Your Critical Systems, IEEE Computer, 1999. 6.Fred Long, CERT Secure Coding Standards: Error Handling, https://www.securecoding.cert.org/confluence/display/cplusplus/1 2.+Error+Handling+(ERR), 2009. https://www.securecoding.cert.org/confluence/display/cplusplus/1 2.+Error+Handling+(ERR) 7.Steve McConnell, Code Complete, 2 nd edition, Microsoft Press, 2004.

21. CSC 666: Secure Software Engineering Privacy Topics 1.Regulations 2.Cryptography 3.Random numbers 4.Passwords 5.Secrets in memory

22. CSC 666: Secure Software Engineering Regulations Regulations protect private data  Children’s Online Protection Act (COPPA)  Federal Information Security Management Act  Gramm-Leach-Bliley Act (GLBA)  Health Insurance Portability & Accountability Act  Payment Card Industry DSS Personally Identifiable Information (PII)  Credit cards  SSNs and state/driver IDs  Names

23. CSC 666: Secure Software Engineering Inbound Passwords  Used to authenticate users to application.  Stored in hashed + salted format.  Hashed: one-way encryption. -MD5 -SHA-1 -SHA-2: SHA-224,256,384,512  Salted: increases time for dictionary attacks -Old UNIX crypt passwords use 12-bit salt. -OpenBSD uses 128-bit salt value.

24. CSC 666: Secure Software Engineering Outbound Passwords Used by app to auth to db, other systems.  Must be accessible in cleartext at some point. Solutions  Store in source code. -Easy to view in source or binary form.  Store cleartext in a configuration file.  Store encrypted in a configuration file. -Use a good, known algorithm like AES. -Limit ACLs so only app can access.  Require admin enter password on restart. -PCI 3.6.6 requires key be split among admins.

25. CSC 666: Secure Software Engineering Key Generation Choose key from set of K keys at random.  Equivalent to selecting a random number between 0 and K–1 inclusive.  Ensures all keys are equally probable to use. Problem: generating random numbers  Computer generated numbers are pseudo-random, that is, generated by an algorithm.  Need direct or indirect hardware sources to obtain sufficiently random data for key generation.

26. CSC 666: Secure Software Engineering PRNGs  Computers are deterministic  Can’t produce true random numbers.  Pseudo-random numbers appear to be random to certain statistical tests.  Tests can be derived from compression.  If you can compress sequence, it’s not random.  Software generated pseudo-random sequences are periodic and predictable.

27. CSC 666: Secure Software Engineering Seeds  Input used to generate initial PR number.  Should be computationally infeasible to predict  Generate seed from random, not PR, data.  Large seed: 32 bits too small; only 2 32 combinations.  Sequence still repeats, but starts from different point for each different seed.  Identical sequences produced for identical seeds.  Period needs to be large for security.

28. CSC 666: Secure Software Engineering Linear Congruential Generator n k = (an k–1 + b) mod m m Modulus (a large prime integer) a Multiplier (integer from 2..m-1) b Increment n 0 Sequence initializer (seed) Functions like rand() in C use LCGs.

29. CSC 666: Secure Software Engineering Hardware Sources Radioactive Decay  Hotbits: 256 bits/s  http://www.fourmilab.ch/hotbits/ http://www.fourmilab.ch/hotbits/ Thermal Noise  Comscire QNG Model J1000KU, 1 Mbit/s  Pentium III RNG LavaRnd  SGI used LavaLite; LavaRnd uses lenscapped digicam  http://www.lavarnd.org/ http://www.lavarnd.org/  up to 200 kbits/s

30. CSC 666: Secure Software Engineering Software Sources Less Secure, More Convenient  Software sufficiently complex to be almost impossible to predict. User Input: Push, don’t Pull  Record time stamp when keystroke or mouse event occurs.  Don’t poll most recent user input every.1s -Far fewer possible timestamps.

31. CSC 666: Secure Software Engineering Software Sources: /dev/random Idea: use multiple random software sources.  Store randomness in pool for user requests.  Use hash functions (i.e., strong mixing functions) to distill data from multiple sources. /dev/random can use random sources such as  CPU load  disk seeks  kernel interrupts  keystrokes  network packet arrival times  /dev/audio sans microphone

32. CSC 666: Secure Software Engineering Software Sources: /dev/random /dev/random  each bit is truly random.  blocks unless enough random bits are available. /dev/urandom  supplies requested number of bits immediately.  reuses current state of pool—lower quality randomness.

33. CSC 666: Secure Software Engineering Poor Entropy: Netscape 1.1  SSL encryption  generates random 40- or 128-bit session key  Netscape 1.1 seeded PRNG with -time of day -PID and PPID  All visible to attacker on same machine.  Remote attack broke keys in 30 seconds  guessed limited randomness in PID/PPID.  packet sniffing can determine time of day.

34. CSC 666: Secure Software Engineering Cryptographic APIs  Cryptlib (free for noncommercial)  Crypt++ (public domain)  Crypt:: CPAN modules (various)  Java Cryptography Architecture  Java Cryptography Extension  Microsoft CryptoAPI  Nettle (GPL)  OpenSSL (OpenSSL license)

35. CSC 666: Secure Software Engineering Supported Ciphers Range of MAC algorithms  Almost all include MD5, SHA-1 Range of symmetric algorithms  Almost all include AES, DES Range of public key algorithms  Almost all include RSA, Diffie-Hellman, DSA

36. CSC 666: Secure Software Engineering 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

37. CSC 666: Secure Software Engineering 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.

38. CSC 666: Secure Software Engineering 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);

39. CSC 666: Secure Software Engineering Erasing Secrets Securely Garbage collecting languages  Essentially impossible to ensure secrets are erased immediately. Low level languages  Use SecureZeroMemory() in Windows.  Use volatile pointers to prevent compiler from optimizing away memory overwrites.

40. CSC 666: Secure Software Engineering Erasing Secrets Securely void auth_function() { char pass[32]; if (getpass(pass)) { // Do something with password } memset(pass, 0, sizeof(pass)); // Prevent memset from being optimized // away by using volatile pointers. *(volatile char *)pass = *(volatile char *)pass; }

41. CSC 666: Secure Software Engineering References 1.Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison- Wesley, 2007. 2.D. Eastlake, “Randomness Recommendations for Security,” RFC 1750, http://www.ietf.org/rfc/rfc1750.txt, 1994. http://www.ietf.org/rfc/rfc1750.txt 3.Ian Goldberg and David Wagner, “Randomness and the Netscape Browser,” Doctor Dobbs’ Journal, 1996. http://www.cs.berkeley.edu/~daw/papers/ddj- netscape.html 4.Michael Howard and David LeBlanc, Writing Secure Code, 2 nd edition, Microsoft Press, 2003. 5.Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, Handbook of Applied Cryptography, http://www.cacr.math.uwaterloo.ca/hac/, CRC Press, 1996.Alfred J. MenezesPaul C. van OorschotScott A. Vanstonehttp://www.cacr.math.uwaterloo.ca/hac/ 6.S. K. Park, K. W. Miller, “Random number generators: good ones are hard to find,” Communications of the ACM, Volume 31 Issue 10, October 1988.Random number generators: good ones are hard to find 7.Bruce Schneier, Applied Cryptography, 2 nd edition, Wiley, 1996. 8.John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. 9.David Wheeler, Secure Programming for UNIX and Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs- HOWTO/index.html, 2003. http://www.dwheeler.com/secure-programs/Secure-Programs- HOWTO/index.html