James Walden Northern Kentucky University Integer Overflows James Walden Northern Kentucky University

CSC 666: Secure Software Engineering Topics Computer Integers Integers in C and Java Overflow Examples Checking for Overflows CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Integer Overflow December 25, 2004 Flight crew scheduling software stopped. Cancelled all 1100 flights that day. What happened? Winter weather led to many crew changes. Number of changes > 32,767 http://www.computerbytesman.com/security/comair.htm http://web.archive.org/web/20070409165930/http://www.cincypost.com/2004/12/28/comp12-28-2004.html https://en.wikipedia.org/wiki/2004_Christmas_Eve_snowstorm CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Integers Computer integers are not the same set of numbers as mathematical integers. Finite set, not infinite. What happens when integer calculations result in a number outside that set? CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Unsigned Integers 7 1 000 111 001 6 110 010 2 101 011 100 3 5 4 CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Two’s Complement Two’s complement = One’s complement + 1. Sign is represented by most significant bit. Range: -2n-1..2n-1-1, only one representation of 0. +75 0 1 0 0 1 0 1 1 Comp 1 0 1 1 0 1 0 0 +1 0 0 0 0 0 0 0 1 -75 1 0 1 1 0 1 0 1 Provides a range from -128 to 127, as there is only one representation for zero and no representation for +128 (would be 1000000, which is used for -128, not +128, as most significant bit is sign.) CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Two’s Complement 1 -1 000 111 001 -2 110 010 2 101 011 100 3 -3 -4 CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering http://pervasive2.morselli.unimo.it/~nicola/courses/IngegneriaDelSoftware/java/DataRepresentation.html CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering C Integers Type Bits Min Value Max Value signed char 8 -128 127 unsigned char 255 short 16 -32768 32767 unsigned short 65535 int 32 -2,147,483,648 2,147,483,647 unsigned int 4,294,967,295 long unsigned long long long 64 -9.223 x 1018 9.223 x 1018 unsigned long long 1.844 x 1019 CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Java Integers Type Bits Min Value Max Value byte 8 -128 127 short 16 -32768 32767 char 65535 int 32 -2,147,483,648 2,147,483,647 long 64 -9.223 x 1018 9.223 x 1018 http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9151 CSC 666: Secure Software Engineering

Java Factorial Program public static void main(String args[]) { long product = 1; for(int i = 1; i <= 21; i++) System.out.print(i); System.out.print("! = "); product *= i; System.out.println(product); } CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Output 1! = 1 2! = 2 3! = 6 …. 20! = 2432902008176640000 21! = -4249290049419214848 CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Java BigInteger Class import java.math.BigInteger; public class BigFactorials { public static void main(String args[]) BigInteger product = BigInteger.ONE; BigInteger index = BigInteger.ONE; for(int i = 1; i <= 21; i++) System.out.print(i); System.out.print("! = "); product = product.multiply(index); System.out.println(product); index = index.add(BigInteger.ONE); } CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Output 1! = 1 2! = 2 3! = 6 …. 20! = 2432902008176640000 21! = 51090942171709440000 CSC 666: Secure Software Engineering

Problems of Integer Overflows Difficult to detect after they’ve happened. Compilers generally ignore them. Assembly code can check carry flag, but high level languages can’t without calling assembly code. Difficult to avoid. Subtle bugs can result in integer overflows. CSC 666: Secure Software Engineering

Integer Overflows in Voting Broward County 2004 election Amendment 4 vote was reported as tied. Software from ES&S Systems reported a large negative number of votes. Discovery revealed that Amendment 4 had passed by a margin of over 60,000 votes. http://www.news4jax.com/politics/3890292/detail.html http://www.evoting-experts.com/index.php?p=81 CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering TKADV2009-002 Integer overflows in Amarok media player. Reads input size + input from file. Allocates input size + 1 bytes, which can be very small. Reads file data into very small buffer, leading to a buffer overflow. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Strip Extension void StripExtension(char * filename) { unsigned short int newSize = strlen(filename) - 4; char * buffer = (char *)malloc(newSize + 1); strncpy(buffer, filename, newSize); buffer[newSize] = ‘\0’; printf(“%s”, buffer); free(buffer); } CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Valid Use What would happen if StripExtension were called as follows? StripExtension(“a.txt”); CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Invalid Use What would happen if StripExtension were called as follows? // User failed to include the extension. StripExtension(“a”); CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Answer newSize = 0xffffd = (1 minus 4) = -3 newSize is an unsigned short integer This value is 65533. The function creates a 65534-byte buffer. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Unsigned Addition An unsigned addition unsigned int x, y, sum; sum = x + y; Precondition if( x > UINT_MAX – y) /* error */ Postcondition if( (x >= 0 && sum < y) || (x < 0 && sum > y) ) /* error */ CSC 666: Secure Software Engineering

Signed Addition Preconditions x y Precondition Positive if (x > INT_MAX – y) /* error */ Negative None if (x < INT_MIN – y) /* error */ Integer.MAX_VALUE, Integer.MIN_VALUE in Java instead of INT_MAX, INT_MIN http://msdn2.microsoft.com/en-us/library/ms972705.aspx CSC 666: Secure Software Engineering

Integer Multiplication Overflow CESA-2004-001: libpng info_ptr->row_pointers = (png_bytepp)png_malloc(png_ptr, info_ptr->height * sizeof(png_bytep)); If height > INT_MAX / sizeof(png_bytep) Size of new buffer will be a small integer. User data in image file can overflow buffer. http://scary.beasts.org/security/CESA-2004-001.txt new operator in C++ is dangerous as malloc: http://blogs.msdn.com/oldnewthing/archive/2004/01/29/64389.aspx https://en.wikipedia.org/wiki/Portable_Network_Graphics CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Widening Conversions A conversion from a type with a smaller range of values to type with a larger range of values. Examples: byte -> short, short -> long Sign extension Propagates signed bit from source type to all unused bits in destination type. Magnitude and sign are preserved. http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html CSC 666: Secure Software Engineering

Widening Conversion Example Source type: byte Value: -7 1 1 1 1 1 0 0 1 Destination type: short 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 CSC 666: Secure Software Engineering

Narrowing Conversions Conversions from a wider type to a narrower type. Examples: long -> byte, int -> short Truncation Bits from source type that don’t fit into narrower destination type are discarded. Magnitude and sign may change. http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html CSC 666: Secure Software Engineering

Narrowing Conversion Example Source Type: short Value: 257 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 Destination Type: byte Value:1 0 0 0 0 0 0 0 1 CSC 666: Secure Software Engineering

Sign Extension Vulnerability CERT CA-1996-22: bash yy_string_get() reads user data as chars. Each char converted to an int when parsed. A char value of 255 sign extended to int -1. Integer -1 means command separator. Example exploit bash -c 'ls\377who' http://www.cert.org/advisories/CA-1996-22.html CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Range Checking Check that integer ranges are valid. Be more specific than INT_MIN, INT_MAX. Liquid water temperatures range 0..100. Use type system to check. Some languages allow integer ranges. Create abstract data types in languages that don’t provide integer range types. CSC 666: Secure Software Engineering

Proposal: Ranged Integers in C All integer types can be ranged. Static: range determined at compile time. Dynamic: range determined at run time. Semantics Saturation: values beyond range = max. Wrap: values wrap to bottom of range. Examples Saturation: int 0|..|100 temperature = 0 Wrap: long min<..>max circular; CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Compiler Checks Microsoft VS 2005 CL Runtime integer error checks: /RTCc Use highest warning level /W4 Check for #pragma warning(disable, C####) GCC Runtime integer error checks: -ftrapv Use integer-relevant warnings: -Wconversion –Wsign-compare Check for #pragma GCC diagnostic ignored option CSC 666: Secure Software Engineering

Secure Integer Libraries Designed for C, but usable in C++. Available from CERT. IntSafe C library written by Michael Howard. Uses architecture specific inline assembly. SafeInt C++ template class from David LeBlanc. CSC 666: Secure Software Engineering

SafeInt<T> C++ Class int main(int argc, char *const *argv) { try { SafeInt<unsigned long> s1(strlen(argv[1])); SafeInt<unsigned long> s2(strlen(argv[2])); char *buff = (char *) malloc(s1 + s2 + 1); strcpy(buff, argv[1]); strcat(buff, argv[2]); } catch(SafeIntException err) { abort(); } CSC 666: Secure Software Engineering

When to use Secure Int Libraries? Use Secure Integer libraries when Integers come from untrusted sources. Don’t use Secure Integer libraries when Integers not influenced by external sources. Tight loops: check int values before loop. CSC 666: Secure Software Engineering

Integer Overflow: Key Points Integer arithmetic. Two’s complement format signed ints. Know your language’s integer conversions. Impact of integer overflows Can be used to defeat bounds checks. Influence important data, like vote counts. Mitigating integer overflows. Precondition or postcondition testing. Use safe integer libraries where possible. CSC 666: Secure Software Engineering

References Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. Jeff Gennari et. al., Ranged Integers for the C Programming Language. CMU/SEI-2007-TN-027, 2007. Michael Howard and David LeBlanc, Writing Secure Code, 2nd edition, Microsoft Press, 2003. Robert C. Seacord, Secure Coding in C and C++, Addison-Wesley, 2006. Robert C. Seacord, CERT Secure Coding Standards: Integers, https://www.securecoding.cert.org/confluence/display/seccode/04.+Integers+(INT), 2009. 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.

James Walden Northern Kentucky University Error Handling James Walden Northern Kentucky University

Topics Error Handling Return Codes Exceptions Logging Survivability

Security Impact of Error Handling Information leakage Stack traces Database errors Resource leakage Return on error without de-allocation Exceptions bypass de-allocation 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 CSC 666: Secure Software Engineering

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. 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 int c; while ( ((c = getchar()) != '\n') && !feof(stdin) && !ferror(stdin)) { Example from https://www.securecoding.cert.org/confluence/display/seccode/FIO34-C.+Use+int+to+capture+the+return+value+of+character+IO+functions CSC 666: Secure Software Engineering

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 rsize_t count = 0; errno_t err; err = sprintf_m( buf + count, "%02x ", &count, ((u8 *)&slreg_num)[i] ); if (err != 0) { /* Handle print error */ } CSC 666: Secure Software Engineering

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

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

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

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. 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; The stack is left in an inconsistent state by the throw since top has been incremented, but no element was added. 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. 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_); } } CSC 666: Secure Software Engineering

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

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

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

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.

CSC 666: Secure Software Engineering Privacy Topics Regulations Cryptography Random numbers Passwords Secrets in memory CSC 666: Secure Software Engineering

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

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 Bcrypt (hash with tunable number of rounds) Salted: increases time for dictionary attacks Old UNIX crypt passwords use 12-bit salt. OpenBSD uses 128-bit salt value. CSC 666: Secure Software Engineering

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

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

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

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. 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) b Increment n0 Sequence initializer (seed) Functions like rand() in C use LCGs. CSC 666: Secure Software Engineering

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 and later analog RNG circuit Ivy Bridge Core i3,5,7 digital RNG circuit LavaRnd SGI used LavaLite; LavaRnd uses lenscapped digicam http://www.lavarnd.org/ up to 200 kbits/s CSC 666: Secure Software Engineering

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. 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 dd if=/dev/random of=randbits.bin bs=1 count=4096 dd if=/dev/urandom of=randbits.bin bs=1 count=4096 CSC 666: Secure Software Engineering

Software Sources: /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. dd if=/dev/random of=randbits.bin bs=1 count=4096 dd if=/dev/urandom of=randbits.bin bs=1 count=4096 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. CSC 666: Secure Software Engineering

How to secure random numbers? NIST SP 800-90A recommendations How to generate secure random seeds. How to generate cryptographic random numbers from cryptographic hash and encryption algorithms. See also NIST Cryptographic Toolkit @ http://csrc.nist.gov/groups/ST/toolkit/index.htm Language APIs Java: java.security.SecureRandom Ruby: SecureRandom .NET:  System.Security.Cryptography.RandomNumberGenerator https://www.cigital.com/justice-league-blog/2009/08/14/proper-use-of-javas-securerandom/ http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf CSC 666: Secure Software Engineering

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

CSC 666: Secure Software Engineering Supported Ciphers Range of MAC algorithms Almost all include MD5, SHA-1, SHA-2. SHA-3 certified Oct 2012, not yet included. Range of symmetric algorithms Almost all include AES, DES Range of public key algorithms Almost all include RSA, Diffie-Hellman, DSA CSC 666: Secure Software Engineering

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 Figure 11.2 from Chess & West. Data lifetime of 64MB of sensitive information in freed memory. 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. 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); 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. 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; CSC 666: Secure Software Engineering

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

James Walden Northern Kentucky University Privileged Programs James Walden Northern Kentucky University

Topics Privilege Escalation SetUID Race Conditions

CSC 666: Secure Software Engineering Privilege Escalation Privileged programs: programs that have privileges to perform operations that the user running them would not otherwise have the right to do. Privilege escalation: Using a privileged program to obtain additional privileges beyond those the user ordinarily has. Vertical: user gains uncontrolled access to the privileged program and is able to perform any action the privileged user could perform. Horizontal: user uses program to gain access to other users’ data that he would not otherwise be able to see. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering UNIX User IDs Real User ID (UID or RUID) The owner of the process. Effective User ID (EUID) The UID used by the operating system to make access control decisions. Saved User ID (SUID) Stores previous UID so that it can be restored later. Usually set to EUID when a SETUID program starts. CSC 666: Secure Software Engineering

Propagation of User IDs fork() All new processes created via fork(). Child process inherits the 3 UIDs from parent. exec() Loads a program image from a file. Does not change UIDs unless The program is SETUID, in which case EUID and SUID are set to UID of file owner. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering SetUID Programs login: Uses SetUID privilege to change user IDs to those of user who successfully authenticates to login program. See also ssh, vmware-authd. passwd: Uses SetUID privilege to modify /etc/shadow to change the user’s password. crontab: Requires SetUID privilege to install and modify cron configuration files for users. ping: Uses SetUID privilege to access raw network sockets and send broadcasts. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Privilege Profiles CSC 666: Secure Software Engineering

Privilege Management Functions Description setuid(uid_t uid) Sets EUID of current process. If EUID of caller is root, sets RUID + SUID too. seteuid(uid_t euid) Sets EUID of current process. Unprivileged processes may only set EUID to RUID, EUID, or SUID. setreuid(uid_t ruid, uid_t euid) Sets RUID + EUID of current process. If RUID or EUID set to a value not equal to previous RUID, SUID set to new EUID. setresuid(uid_t ruid, uid_t euid, uid_t suid) Sets RUID, EUID, and SUID of current process. Supply -1 for each RUID or EUID leaves that ID unchanged. Unprivileged processes may set IDs only to current RUID, EUID, or SUID. Nonzero returns are failures. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Chen, Wagner, Dean API Function Description drop_priv_temp( uid_t new_uid) Drop privileges temporarily. Move current privileged UID from EUID to SUID. Assign new_uid to EUID. drop_priv_perm( Drop privileges permanently. Assign new_uid to RUID, EUID, and SUID. restore_priv() Copy privileged user ID from SUID to EUID. From SetUID Demystified. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Linux Capabilities Divide monolithic root into capabilities. Examples: Capability Description CAP_CHOWN Change ownership, overriding DAC. CAP_LINUX_IMMUTABLE Allow modification of S_IMMUTABLE and S_APPEND file attributes. CAP_NET_BIND_SERVICE Allow binding to ports below 1024. CAP_NET_BROADCAST Allow broadcast, listening to multicast. CAP_NET_RAW Allow use of raw network sockets. CAP_SYS_CHROOT Allow use of chroot(). CAP_SYS_PTRACE Allow ptrace() of any process. CAP_SYS_BOOT Allow use of reboot(). CAP_SYS_NICE Allow raising and setting process priority. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Linux Capabilities Files and processes have 3 capability sets: Inheritable: capabilities that will be inherited by child processes. Permitted: capabilities that the current process can obtain if it requests them. Effective: capabilities that will be applied to access control decisions for current process. Capabilities set when executing a program pI’ = pI pP’ = (X & fP) | (pI & fI) pE’ = fE ? pP’ : Ø where X is per-process capability bounding set. CSC 666: Secure Software Engineering

Limit Filesystem Privilege Use chroot(path) to change system root. Program sees path as /. All files needed must be under path. /etc/passwd: only contains necessary accounts /lib/libc.so: and any other shared libraries. How to chroot() safely. Close all open file descriptors. Call chroot(), check errs, then chdir(). Drop privileges. CSC 666: Secure Software Engineering

Breaking out of a chroot() jail Re-chroot() with open filehandle above new root Create temporary directory in CWD. Open CWD, keeping an open fh above tmpdir. Chroot(tmpdir) Use fchdir() with CWD fh to move CWD outside the chrooted area. Perform chdir(‘..’) to move CWD to /. Chroot(‘.’), making root the real /. Direct disk access Use mknod() to create a raw disk device. Edit files directly using raw disk. Direct memory access Use mknod() to create /dev/kmem. Modify /dev/kmem to alter running OS kernel. CSC 666: Secure Software Engineering

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. Race conditions are always a reliability issue, but sometimes also a security flaw. CSC 666: Secure Software Engineering

Java Servlet Hit Counter // Example from BSS, pp. 210-211 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!"); } Calculates number of times web page has been accessed. CSC 666: Secure Software Engineering

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” Cannot be fixed by expressing the two statements as one: p.println(++count + “ hits so far!”) It requires multiple JVM byte code instructions to execute the statement. CSC 666: Secure Software Engineering

Window of Vulnerability Period of time when violating assumption about order of events will produce incorrect behavior. Generally <1s under ordinary conditions. Small windows can be exploited. Attackers can send multiple requests. Attackers can slow the system down. Local attackers may be able to suspend a process indefinitely with SIGSTOP. Only secure window is one of zero size. CSC 666: Secure Software Engineering

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

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!"); Java provides synchronized keyword for critical sections. Note limitation of critical section to only required code. CSC 666: Secure Software Engineering

Time of Check, Time of Use TOCTOU Security Flaw Perform access control check of resource. Access resource. Problem Has resource ACL changed between steps? Has resource changed between steps, perhaps pointing to a different file or URL? CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering 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); } Kernel performs access checks based on EUID/EGID, so setuid root program can always open() a file regardless of permissions. Access() function checks based on real UID/GID. Sounds useful in SETUID programs, but access() always insecure because of race condition. Ignore advice to use in Stevens, p. 82. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering 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 Historically xterm was setuid to access utmp. Could write log file to save xterm session. Developer’s Invalid Assumption: filename refers to the same object in both access() and open() calls. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering ex: passwd [Bishop, 1996] passwd: allows user-specified passwd file Normal functioning opens passwd file + reads user entry; closes creates + opens temp file ptmp in same directory opens passwd file again, then copies contents to ptmp with user changes closes both passwd and ptmp files; renames ptmp to passwd Doesn’t modify passwd in place to avoid problems with programs reading partially modified passwd file. UNIX move action is atomic. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering 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 Attack directory can be any directory attacker has write access to. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering passwd attack setup mkdir attackdir echo “localhost attacker :::::” > attackdir/.rhosts # want link to point to attackdir for step 1 ln –s attackdir link # specify password file using symlink dir passwd link/.rhosts CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering passwd: step by step passwd program opens + reads link/.rhosts actual file: attackdir/.rhosts Attacker changes link to point to /user passwd program creates + opens link/ptmp actual file: /user/ptmp Attacker changes link to point to attackdir CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering passwd: step by step passwd program opens link/.rhosts actual file: attackdir/.rhosts passwd program copies contents to ptmp actual file: /user/ptmp Attacker changes link to point to /user CSC 666: Secure Software Engineering

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

CSC 666: Secure Software Engineering 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 File descriptors are initially obtained using a system call with a pathname. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering TOCTOU Binding Flaws Occur with two sequential system calls: insecure: Both call refer to same object by pathname. insecure: One call uses file descriptor, other uses pathname. secure: First call binds file descriptor to pathname, second uses that file descriptor. Solution: use calls that use file descriptors. Problem: some calls require pathnames. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering TOCTOU Binding Flaws Solution: use calls that use file descriptors. fchmod() instead of chmod() fchown() instead of chown() fstat() instead of stat() Problem: calls that only use pathnames. link(), unlink(), symlink() mkdir(), rmdir() CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Safe File Open lstat() file before opening, saving stat structure. open() file, obtaining file descriptor use O_CREAT | O_EXCL flags. specify permissions in open() call or use safe umask. fstat() on file descriptor, saving stat structure. Compare permissions (st_mode), inode (st_ino), and device (st_dev) of two stat structures. If identical, we know lstat() happened on same file we opened and that we did not follow a link. Remember lstat() gives stat on symbolic link, whereas stat() will give stat on file that is linked to. Code in BSS, pp. 220-222. CSC 666: Secure Software Engineering

Safe setuid File Operations Using access() is always a race condition. Change process EUID/EGID to the real UID/GID we want to use for check. setreuid( EUID, UID ) Perform file operations (access checks will apply to EUID/EGID). Change back to privileged EUID/EGID when privileges needed again. setreuid( UID, EUID ) EUID=program owner, UID=runner of program Only two UID changes allowed for non-setuid root programs: 1. Swap EUID, UID 2. Set EUID to UID CSC 666: Secure Software Engineering

When pathnames are necessary Keep files in their own, safe directory. Set perms so only UID of program can access. Ensure parent directories are secure too. mkdir safe directory chdir safe directory chdir .. + check permissions until reach root CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering Temporary Files C library Filename generation functions: always a race. tmpfile()insecure, varies between UNIXes. mkstemp() is best choice, but Creates files with mode 0666 on older systems. Can lead to a dential of service if attacker precreates files. Solution: use private dir for temporary files. Create directory securely. Set permissions so only program can execute. Use unlink() on files after creation to ensure cleanup even if program crashes. Tmpcleaner vulnerabilities. Never close and re-open a file, or use filename in any way. CSC 666: Secure Software Engineering

CSC 666: Secure Software Engineering References Matt Bishop. “How Attackers Break Programs, and How to Write Programs More Securely”, SANS 2002, Baltimore, MD (May 2002). M. Bishop and M. Dilger, "Checking for Race Conditions in UNIX File Accesses," Technical Report 95-9, Department of Computer Science, University of California at Davis (Sep. 1995). [PDF] [PS] Hao Chen, David Wagner, and Drew Dean. “SetUID Demystified.” Proceedings of the USENIX Security Conference. 2002. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. Mark Dowd, John McDonald, and Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007. Serge Hallyn and ANdrew Morgan, “Linux Capabilities: making them work,” Proceedings of the Linux Symposium, July 23-26 2008. 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. CSC 666: Secure Software Engineering