Error Handling

1. James Walden Northern Kentucky University Error Handling

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

21. CSC 666: Secure Software Engineering Privacy Topics • Regulations • Cryptography • Random numbers • Passwords • 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 232 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 nk = (ank–1 + b) mod m m Modulus (a large prime integer) a Multiplier (integer from 2..m-1) bIncrement n0 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/ Thermal Noise • Comscire QNG Model J1000KU, 1 Mbit/s • Pentium III RNG LavaRnd • SGI used LavaLite; LavaRnd uses lenscapped digicam • 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 • Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. • D. Eastlake, “Randomness Recommendations for Security,” RFC 1750, http://www.ietf.org/rfc/rfc1750.txt, 1994. • Ian Goldberg and David Wagner,“Randomness and the Netscape Browser,” Doctor Dobbs’ Journal, 1996. http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html • Michael Howard and David LeBlanc, Writing Secure Code, 2nd edition, Microsoft Press, 2003. • 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. • 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. • Bruce Schneier, Applied Cryptography, 2nd edition, Wiley, 1996. • John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. • David Wheeler, Secure Programming for UNIX and Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.