1. James Walden Northern Kentucky University
Integer Overflows
James Walden
Northern Kentucky University

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

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

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

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

6. 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.
Comp
Provides a range from -128 to 127, as there is only one representation for zero and no representation for +128 (would be , which is used for -128, not +128, as most significant bit is sign.)
CSC 666: Secure Software Engineering

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

8. CSC 666: Secure Software Engineering
CSC 666: Secure Software Engineering

9. 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
x 1018
9.223 x 1018
unsigned long long
1.844 x 1019
CSC 666: Secure Software Engineering

10. 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
x 1018
9.223 x 1018
CSC 666: Secure Software Engineering

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

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

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

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

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

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

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

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

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

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

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

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

23. Signed Addition Preconditionsx 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
CSC 666: Secure Software Engineering

24. Integer Multiplication Overflow
CESA : 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.
new operator in C++ is dangerous as malloc:
CSC 666: Secure Software Engineering

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

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

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

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

29. Sign Extension Vulnerability
CERT CA : 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'
CSC 666: Secure Software Engineering

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

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

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

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

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

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

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

37. 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,
John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
David Wheeler, Secure Programming for UNIX and Linux HOWTO,

38. James Walden Northern Kentucky University
Error Handling
James Walden
Northern Kentucky University

39. Topics
Error Handling
Return Codes
Exceptions
Logging
Survivability

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

41. 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 , 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

57. 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,
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,
Steve McConnell, Code Complete, 2nd edition, Microsoft Press, 2004.

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

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

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

61. 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 requires key be split among admins.
CSC 666: Secure Software Engineering

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

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

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

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

66. CSC 666: Secure Software Engineering
Hardware Sources
Radioactive Decay
Hotbits: 256 bits/s
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
up to 200 kbits/s
CSC 666: Secure Software Engineering

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

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

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

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

71. How to secure random numbers?
NIST SP A recommendations
How to generate secure random seeds.
How to generate cryptographic random numbers from cryptographic hash and encryption algorithms.
See also NIST Cryptographic
Language APIs
Java: java.security.SecureRandom
Ruby: SecureRandom
.NET:  System.Security.Cryptography.RandomNumberGenerator
CSC 666: Secure Software Engineering

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

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

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

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

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

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

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

79. 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,
Ian Goldberg and David Wagner, “Randomness and the Netscape Browser,” Doctor Dobbs’ Journal,
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, 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,
CSC 666: Secure Software Engineering

80. James Walden Northern Kentucky University
Privileged Programs
James Walden
Northern Kentucky University

81. Topics
Privilege Escalation
SetUID
Race Conditions

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

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

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

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

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

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

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

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

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

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

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

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

94. Java Servlet Hit Counter
// Example from BSS, pp
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

115. 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
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
John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
David Wheeler, Secure Programming for UNIX and Linux HOWTO,
CSC 666: Secure Software Engineering