Integer Overflows James Walden Northern Kentucky University
Feb 24, 2016
Integer Overflows
James WaldenNorthern Kentucky University
CSC 666: Secure Software Engineering
Topics
1. Computer Integers2. Integers in C and Java3. Overflow Examples4. Checking for Overflows
CSC 666: Secure Software Engineering
Integer OverflowDecember 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
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
Unsigned Integers
000
001
010
011
100
101
110
111
0
1
2
3
4
5
6
7
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 1Comp
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
CSC 666: Secure Software Engineering
Two’s Complement
000
001
010
011
100
101
110
111
0
1
2
3
-4
-3
-2
-1
CSC 666: Secure Software Engineering
CSC 666: Secure Software Engineering
C Integers
Type Bits Min Value Max Valuesigned char 8 -128 127unsigned char 8 0 255short 16 -32768 32767unsigned short 16 0 65535int 32 -2,147,483,648 2,147,483,647unsigned int 32 0 4,294,967,295long 32 -2,147,483,648 2,147,483,647unsigned long 32 0 4,294,967,295long long 64 -9.223 x 1018 9.223 x 1018
unsigned long long 64 0 1.844 x 1019
CSC 666: Secure Software Engineering
Java IntegersType Bits Min Value Max Value
byte 8 -128 127
short 16 -32768 32767
char 16 0 65535
int 32 -2,147,483,648 2,147,483,647
long 64 -9.223 x 1018 9.223 x 1018
CSC 666: Secure Software Engineering
Java Factorial Programpublic 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
Output
1! = 12! = 23! = 6….20! = 243290200817664000021! = -4249290049419214848
CSC 666: Secure Software Engineering
Java BigInteger Classimport 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
Output
1! = 12! = 23! = 6….20! = 243290200817664000021! = 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 electionAmendment 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.
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
Strip Extensionvoid 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
Valid Use
What would happen if StripExtension were called as follows?
StripExtension(“a.txt”);
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
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
Unsigned Addition
An unsigned additionunsigned int x, y, sum;sum = x + y;
Preconditionif( x > UINT_MAX – y) /* error */
Postconditionif( (x >= 0 && sum < y) || (x < 0 && sum > y) )
/* error */
CSC 666: Secure Software Engineering
Signed Addition Preconditionsx y Precondition
Positive Positive if (x > INT_MAX – y) /* error */
Positive Negative None
Negative Positive None
Negative Negative if (x < INT_MIN – y) /* error */
CSC 666: Secure Software Engineering
Integer Multiplication OverflowCESA-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.
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 -> longSign extension
Propagates signed bit from source type to all unused bits in destination type.Magnitude and sign are preserved.
CSC 666: Secure Software Engineering
Widening Conversion Example
Source type: byte Value: -71 1 1 1 1 0 0 1
Destination type: short Value: -71 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 -> shortTruncation
Bits from source type that don’t fit into narrower destination type are discarded.Magnitude and sign may change.
CSC 666: Secure Software Engineering
Narrowing Conversion Example
Source Type: shortValue: 2570 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1
Destination Type: byteValue:10 0 0 0 0 0 0 1
CSC 666: Secure Software Engineering
Sign Extension Vulnerability
CERT CA-1996-22: bashyy_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 exploitbash -c 'ls\377who'
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.
SemanticsSaturation: values beyond range = max.Wrap: values wrap to bottom of range.
ExamplesSaturation: int 0|..|100 temperature = 0Wrap: long min<..>max circular;
CSC 666: Secure Software Engineering
Compiler ChecksMicrosoft 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
IntegerLib– 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 whenIntegers come from untrusted sources.
Don’t use Secure Integer libraries whenIntegers 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.
References1. Brian Chess and Jacob West, Secure Programming with Static
Analysis, Addison-Wesley, 2007.2. Jeff Gennari et. al., Ranged Integers for the C Programming
Language. CMU/SEI-2007-TN-027, 2007.3. Michael Howard and David LeBlanc, Writing Secure Code, 2nd
edition, Microsoft Press, 2003.4. Robert C. Seacord, Secure Coding in C and C++, Addison-
Wesley, 2006.5. Robert C. Seacord, CERT Secure Coding Standards: Integers,
https://www.securecoding.cert.org/confluence/display/seccode/04.+Integers+(INT), 2009.
6. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
7. David Wheeler, Secure Programming for UNIX and Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.
Error Handling
James WaldenNorthern Kentucky University
Topics
1. Error Handling2. Return Codes3. Exceptions4. Logging5. Survivability
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
CSC 666: Secure Software Engineering
Error Handling TechniquesReturn 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
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 functionsfgetc(), 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 examplechar 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 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 libraryint 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 */ }
CSC 666: Secure Software Engineering
Resource LeaksResources leak due to early returns
– Memory– Filehandles
Examplechar *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 handlingProblem: 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 gotochar *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
ExceptionsAdvantages 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
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
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 Examplevoid 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;
}
CSC 666: Secure Software Engineering
Catch-all Exception HandlersEnsure no information leakage at top level functions.
doGet(), doPost(), web service entry pointsprotected 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-AllocationResource 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.
Examplefile (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
Finally
Finally block executed regardless of whether an exception is caught or not.
ExampleStatement stmt = conn.createStatement();try {stmt.execute(sqlString);
} finally {if (stmt != null ) { stmt.close(); }
}
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
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
References1. David Abrahams, Exception-Safety in Generic Components.
Lecture Notes In Computer Science: 69-79, 2000.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/attachments/3524/error-handling.pdf, 2006.
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/12.+Error+Handling+(ERR), 2009.
7. Steve McConnell, Code Complete, 2nd edition, Microsoft Press, 2004.
CSC 666: Secure Software Engineering
Privacy Topics
1. Regulations2. Cryptography3. Random numbers4. Passwords5. Secrets in memory
CSC 666: Secure Software Engineering
RegulationsRegulations 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
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
Outbound PasswordsUsed 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
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
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
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 Incrementn0 Sequence initializer (seed)
Functions like rand() in C use LCGs.
CSC 666: Secure Software Engineering
Hardware SourcesRadioactive 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
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
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.
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.htmLanguage APIs
Java: java.security.SecureRandomRuby: SecureRandom.NET: System.Security.Cryptography.RandomNumberGenerator
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
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
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 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 MemoryPrevent secrets from paging to disk.
Does not prevent suspend or hibernate saving pages.
Linux page lockingmlock(const void *addr, size_t len)munlock(const void *addr, size_t len)
Windows page lockingVirtualLock(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 Securelyvoid 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
References1. 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.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, 2nd 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.
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.
7. Bruce Schneier, Applied Cryptography, 2nd 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.
Privileged Programs
James WaldenNorthern Kentucky University
Topics
1. Privilege Escalation2. SetUID3. 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
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
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
Privilege Profiles
CSC 666: Secure Software Engineering
Privilege Management Functions
Function Descriptionsetuid(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.
CSC 666: Secure Software Engineering
Chen, Wagner, Dean APIFunction Descriptiondrop_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( uid_t new_uid)
Drop privileges permanently. Assign new_uid to RUID, EUID, and SUID.
restore_priv() Copy privileged user ID from SUID to EUID.
CSC 666: Secure Software Engineering
Linux Capabilities
Divide monolithic root into capabilities. Examples:Capability DescriptionCAP_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
Linux CapabilitiesFiles 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 programpI’ = pIpP’ = (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() jailRe-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.
CSC 666: Secure Software Engineering
Java Servlet Hit Counter// Example from BSS, pp. 210-211public 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 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”
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
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. 213public 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 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
UNIX Exampleint 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 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.
CSC 666: Secure Software Engineering
ex: passwd [Bishop, 1996]
passwd: allows user-specified passwd fileNormal functioning
1. opens passwd file + reads user entry; closes2. creates + opens temp file ptmp in same
directory3. opens passwd file again, then copies
contents to ptmp with user changes4. closes both passwd and ptmp files; renames
ptmp to passwd
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
CSC 666: Secure Software Engineering
passwd attack setupmkdir attackdirecho “localhost attacker :::::” > attackdir/.rhosts
# want link to point to attackdir for step 1
ln –s attackdir link# specify password file using symlink dirpasswd link/.rhosts
CSC 666: Secure Software Engineering
passwd: step by step
passwd program opens + reads link/.rhostsactual file: attackdir/.rhosts
Attacker changes link to point to /user
passwd program creates + opens link/ptmpactual file: /user/ptmp
Attacker changes link to point to attackdir
CSC 666: Secure Software Engineering
passwd: step by step
passwd program opens link/.rhostsactual file: attackdir/.rhosts
passwd program copies contents to ptmpactual file: /user/ptmp
Attacker changes link to point to /user
CSC 666: Secure Software Engineering
passwd: step by step
passwd program closes link/.rhosts + ptmp
passwd program renames ptmp to link/.rhostsactual file: /user/.rhosts
“Password” file is now target user’s .rhostsWe can now rlogin to their account without
needing a password.
CSC 666: Secure Software Engineering
UNIX File Binding
UNIX provides two forms of namingpathname
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 666: Secure Software Engineering
TOCTOU Binding FlawsOccur 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
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
Safe File Open
1. lstat() file before opening, saving stat structure.2. open() file, obtaining file descriptor
1. use O_CREAT | O_EXCL flags.2. specify permissions in open() call or use safe
umask.3. fstat() on file descriptor, saving stat structure.4. 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.
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 )
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
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.
CSC 666: Secure Software Engineering
References1. Matt Bishop. “How Attackers Break Programs, and How to Write
Programs More Securely”, SANS 2002, Baltimore, MD (May 2002). 2. 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]
3. Hao Chen, David Wagner, and Drew Dean. “SetUID Demystified.” Proceedings of the USENIX Security Conference. 2002.
4. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.
5. Mark Dowd, John McDonald, and Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007.
6. Serge Hallyn and ANdrew Morgan, “Linux Capabilities: making them work,” Proceedings of the Linux Symposium, July 23-26 2008.
7. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
8. David Wheeler, Secure Programming for UNIX and Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.