CIT 380: Securing Computer Systems

Transcription

1 CIT 380: Securing Computer Systems Secure Programming Slide #1

2 Topics 1. The nature of trust 2. Input validation 3. Input entry points 4. Integer overflows 5. Format string attacks Slide #2

3 Trust Relationships Relationship between multiple entities. Assumptions that certain properties are true. example: input has a certain format Assumptions that other properties are false. example: input never longer than X bytes Trustworthy entities satisfy assumptions. Slide #3

4 Who do you trust? Client users example: encryption key embedded in client Operating system example: dynamicly loaded libraries Calling program example: environment variables Vendor example: Borland Interbase backdoor , only discovered when program made open source Slide #4

5 Trust is Transitive If you call another program, locally or across the network, you are trusting the entities that it trusts. Processes you spawn run with your privileges. Did you run the program you think you did? PATH and IFS environment variables What input format does it use? Shell escapes in editors and mailers What output does it send you? Slide #5

6 Validate All Input Never trust input. Assume dangerous until proven safe. Prefer rejecting data to filtering data. Difficult to filter out all dangerous input Every component should validate data. Trust is transitive. Don t trust calling component. Don t trust called component: shell, SQL Slide #6

7 Validation Techniques Indirect Selection Allow user to supply index into a list of legitimate values. Application never directly uses user input. Whitelist List of valid patterns or strings. Input rejected unless it matches list. Blacklist List of invalid patterns or strings. Input reject if it matches list. Slide #7

8 Validation Actions Sanitize Attempt to fix input by removing dangerous parts. Reject Refuse to use invalid input. Reject with Explanation Explain problems with input to user. Refuse to use invalid input. Log Record invalid input in log file. Alert Send an alert to an administrator about input. Slide #8

9 Usability Validation Security Validation Usability Validation helps legitimate users Catch common errors. Provide easy to understand feedback. Client-side feedback is helpful for speed. Security Validation mitigates vulnerabilities Catches potential attacks, including unusual, unfriendly types of input. Provide little to no feedback on reasons for blocking input. Cannot trust client. Always server side. Slide #9

10 Check Input Length Long input can result in buffer overflows. Can also cause DoS due to low memory. Truncation vulnerabilities 8-character long username column in DB. User tries to enter admin x as username. DB returns no match since name is 9 chars. App inserts data into DB, which truncates. Later SQL queries will return both names, since MySQL ignores trailing spaces on string comparisons. Slide #10

11 Check Input Type Is input the type you expect? Integer Temperature (integer within specified range) Money value (fixed point) Name (alphabetic string allowing, -, spaces) If not, reject input. Slide #11

12 Python: Input Type Check Example def readinteger(): while True: try: return int(raw_input()) except ValueError: pass Slide #12

13 Check Input Syntax Is input in correct format? Phone number (xxx-xxx-xxxx format) International phone number (more options) Credit card number (format, Luhn checksum) URL address If not, reject input. Slide #13

14 Python: Input Syntax Check import re def readphonenumber(): while True: phone = raw_input() if re.match(r ^[0-9]{3}-[0-9]{4}$', phone): return phone print('invalid phone number. Try again:') Slide #14

15 Regular Expression Validation Beginnings and Endings 1. Begin with ^ to match beginning of input. 2. End with $ to match end of input. 3. Use both to ensure re matches entire input. Optional Components with ()? Syntax ^\d{5}(-\d{4})?$ will match 5- and 9-digit zip codes. Limitations Cannot match complex types of input, such as programming languages or markup languages, or subsets of them, like XML or JSON. Slide #15

16 Input Entry Points 1. Command line arguments 2. Environment variables 3. Paths 4. Shell input 5. Database input 6. Other input types Slide #16

17 Command Line Arguments Scripts access in different ways Python: argv, getopt.getopt class Ruby: ARGV, OptionParser class Shell: $1, $2,, getopt function Check carefully, since there may be an 1. Unlimited number of arguments. 2. Unlimited length of any argument. 3. Argument lengths can even be 0. Slide #17

18 Dangerous Environment Variables PATH Search path for binaries Attacker puts directory with hacked binary first in PATH so his ls used instead of system ls Avoid. as attacker may place hacked binaries in directory program sets CWD to IFS Internal field separator for shell Used to separate command line into arguments Attacker sets to / : /bin/ls becomes bin and ls Slide #18

19 Dangerous Environment Variables LD_PRELOAD Programs loads functions from library specified in LD_PRELOAD before searching for system libraries. Can replace any library function. setuid root programs don t honor this variable. LD_LIBRARY_PATH Specify list of paths to search for shared libs. Store hacked version of library in first directory. Modern libc implementation disallow for setuid/setgid. Slide #19

20 Securing Your Environment Setting a Secure Environment in Shell Create a wrapper script that clears environment #!/bin/bash /usr/bin/env -i /path/to/your/script At the top of your script set needed env variables PATH=/bin:/usr/bin IFS= \t\n Setting a Secure Environment in Ruby ENV = { PATH => /bin:/usr/bin, IFS => \t\n } Slide #20

21 Paths If attacker controls paths used by program Can read files accessible by program. Can write files accessible by program. Vulnerability if access is different than attackers Privileged (SETUID) local programs. Remote server applications, including web. Directory traversal Use../../.. to climb out of application s directory and access files. Slide #21

22 Canonicalization How to make correct access control decisions when there are many names? config./config /etc/program/config../program/config /tmp/../etc/program/config Canonical Name: standard form of a name Generally simplest form. Canonicalize name then apply access control. Use realpath() in C to canonicalize. Slide #22

23 Common Naming Issues. represents current directory.. represents previous directory Case sensitivity Windows allows both / and \ in URLs. Windows 8.3 representation of long names Two names for each file for backwards compat. Trailing dot in DNS names == URL encoding Slide #23

24 Win/Apache Directory Traversal Found in Apache and earlier. To view the file winnt\win.ini, use: 2e%5c%2e%2e%5c%2e%2e%5cwinnt%5cwin.i ni which is the escaped form of Slide #24

25 Command Injection Find program that invokes a subshell command with user input Shell: every command with user input Perl: system(), ``, open() Ruby: system(), ``, %x{}, IO.popen(), etc. Python: os.system(), os.popen(), etc. Attack uses shell meta-characters to insert user-defined code into the command. Slide #25

26 UNIX Shell Metacharacters `command` will execute command ; separates commands creates a pipe between two commands && and logical operators which may execute following command! logical negation reverses truth value of test - could convert filename into an argument * and? glob, matching files, which may be interpreted as args: what if -rf is file? # comments to end of line Slide #26

27 Command Injection in Ruby Vulnerable Code file = gets.chomp system( cat #{file} ) Fixed Code file = gets.chomp system( cat, file) system() argument handling String: send string to bash as command line List: fork and exec first argument w/o bash. Slide #27

28 Unsigned Integers Slide #28

29 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); } } Slide #29

30 Output 1! = 1 2! = 2 3! = 6. 20! = ! = Slide #30

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

32 Format Strings Formatted output functions use format lang. Percent(%) symbols in string indicate substitutions. %[flags][width][.precision][length]specifier Example format specifiers %010d, 2009: %4.2f, : 3.14 Example functions printf() scanf() syslog() Slide #32

33 Format String Vulnerabilities User-specified format strings userstring = foo %x ; printf( userstring ); Where can it find arguments to replace %x? The Stack: %x reads 4-bytes higher in stack Solution: Use printf( %s, userstring ) or fputs( userstring ) Slide #33

34 %n format command Number of characters written so far is stored into the integer indicated by the int * pointer argument. char buf[] = " "; int *n; printf( buf=%s%n\n", buf, n); printf("n=%d\n", *n); Output: buf= n=14 Slide #34

35 %n format attack Plan of Attack Find address of variable to overwrite Place address of variable on stack (as part of format string) so %n will write to that address Write # of characters equal to value to insert into variable (use precision, e.g., %.64x) Use %n to write anywhere in memory Address on stack can point to any location Slide #35

36 Key Points 1. All input must be validated, using best technique possible: 1. Indirect Selection 2. Whitelist 3. Blacklist 2. Check input length, type, and syntax. 1. Regular expressions are useful when used with anchors to whitelist input, but cannot validate languages like XML or JSON. 2. To check URL or filesystem paths, programs must canonicalize them first to avoid path manipulation attacks. 3. Vulnerabilities 1. Buffer overflows overwrite process memory, allowing injection and execute of machine code sent by attacker. 2. Integer overflows allow control of integer variable values. 3. Format string attacks allow reading and writing of memory. Slide #36

37 References 1. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, Goodrich and Tammasia, Introduction to Computer Security, Pearson, John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, David Wheeler, Secure Programming for UNIX and Linux HOWTO, Slide #37