Secure Coding

1. James Walden Northern Kentucky University Secure Coding

2. Topics • Error Handling • Return Codes • Exceptions • Logging • Memory Allocation • Using and Storing Passwords • Protecting Secrets in Memory

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. 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 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. 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; inti = 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; inti = 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 Resource Leaks Resources leak due to early returns • Memory • Filehandles Example char *getblock(intfd) { char *buf = (char *)malloc(1024); if (!buf) { return NULL; } if (read(fd, buf, 1024) != 1024) { return NULL; } return buf }

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

9. CSC 666: Secure Software Engineering Fixed version with goto char *getblock(intfd) { 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; }

10. 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 }

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

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

13. 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(inti = 0; i < top; i++) buf[i] = data[i]; delete [] data; data = buf; } data[top] = element; }

14. 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(HttpServletRequestreq, 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.

15. CSC 666: Secure Software Engineering Destructor De-Allocation Resource Acquisition 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_); } }

16. 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(); } }

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

18. CSC 666: Secure Software Engineering Memory Allocation Strategies Static Buffer Allocation • Advantages: simple, easy to know bounds. • Disadvantages: inflexible, wastes memory. Dynamic Buffer Allocation • Advantages: flexible. • Disadvantages: must check for DoS attacks. Track Buffer Sizes typedefstruct { char* ptr; size_tbufsize; } buffer;

19. Common Allocation Errors • Assuming that memory is zeroed. • Allocated memory contains junk, not zeros. • Failure to check that allocation succeeded. • Most C functions return a NULL pointer on failure. • new will throw std::bad_allocexception on failure. • Unless specify T* p = new(std::nothrow) T; • Use of invalid pointers. • Dereference NULLs, use after free, double free. • Failure to deallocate memory. • Memory leaks. • Zero-length allocations are implementation defined in C.

20. CSC 666: Secure Software Engineering Inbound and Outbound Passwords Inbound Passwords • Used to authenticate users to application. • In cleartext only at point of user data entry. • Risks: online and offline password guessing. Outbound Passwords • Used to authenticate application to other systems, such as databases or CC processors. • Must be in cleartext to use. • Risks: information leakage.

21. Securing Inbound Passwords

22. Offline Password Cracking Password dictionary word = Next dictionary word wordhash= Hash(word) for each (username, hash) wordhash== hash Usernames + Hashed Passwords False True Store(usernames, word)

23. CSC 666: Secure Software Engineering Hashing and Salting MD4 (Windows) • Unlimited password length. • Slow MD4 hash, no salt. SHA512crypt (Linux, Mac OS X) • Unlimited password length. • 5000 iterations of SHA-512 hash function. • 16 character salt. PBKDF2 (Password-Based Key Derivation Function 2) • Framework with configurable hash, iterations, salt. In .NET. Scrypt • Sequential, memory-hard hashing algorithm. • Defense against specialized hardware (GPUs, ASICs, FPGAs)

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

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

27. 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_tlen) munlock(const void *addr, size_tlen) Windows page locking VirtualLock(LPVOID lpAddress, SIZE_T dwSize); VirtualUnlock(LPVOID lpAddress, SIZE_T dwSize);

28. CSC 666: Secure Software Engineering Erasing Secrets Securely Garbage collecting languages • Essentially 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.

29. CSC 666: Secure Software Engineering Erasing Secrets Securely in C99 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; }

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