CIT 480 Securing Computer Systems Secure Programming Slide

  • Slides: 38
Download presentation
CIT 480: Securing Computer Systems Secure Programming Slide #1

CIT 480: Securing Computer Systems Secure Programming Slide #1

Topics 1. 2. 3. 4. 5. 6. Input-based vulnerabilities Input validation Input entry points

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

Path Traversal Vulnerabilities Example web application URL – http: //example. com/getfile. php? file=report. pdf

Path Traversal Vulnerabilities Example web application URL – http: //example. com/getfile. php? file=report. pdf What if URL modified after file= to be? – getfile. php – Could threat read application source code? What if URL modified after file= to be? –. . /etc/passwd – Walks up directory tree to get passwd file. Slide #3

Paths If attacker controls paths used by program – Can read files accessible by

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

Canonicalization How to make correct access control decisions when there are many names? •

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

Common Naming Issues • • • . represents current directory. . represents previous directory

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 – www. nku. edu. == www. nku. edu • URL encoding Slide #6

Win/Apache Directory Traversal Found in Apache 2. 0. 39 and earlier. To view the

Win/Apache Directory Traversal Found in Apache 2. 0. 39 and earlier. To view the file winntwin. ini, use: http: //127. 0. 0. 1/error/%5 c%2 e%2 e%5 c%2 e%2 e%5 cwinnt%5 cwin. i ni which is the escaped form of http: //127. 0. 0. 1/error/. . winntwin. ini Slide #7

Command Injection Find program that invokes a subshell command with user input Shell: every

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

UNIX Shell Metacharacters `command` will execute command ‘; ’ separates commands ‘|’ creates a

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

Command Injection in Ruby Vulnerable Code file = gets. chomp system(“cat #{file}”) Fixed Code

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

Validate All Input Never trust input. – Assume dangerous until proven safe. Prefer rejecting

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

Validation Techniques Indirect Selection – Allow user to supply index into a list of

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

Validation Actions Sanitize – Attempt to fix input by removing dangerous parts. Reject –

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

Usability Validation ≠ Security Validation Usability Validation helps legitimate users – Catch common errors.

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

Check Input Length Long input can result in buffer overflows. – Can also cause

Check Input Length Long input can result in buffer overflows. – Can also cause Do. S 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 My. SQL ignores trailing spaces on string comparisons. Slide #15

Check Input Type Is input the type you expect? – Integer – Temperature (integer

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

Python: Input Type Check Example def read. Integer(): while True: try: return int(raw_input()) except

Python: Input Type Check Example def read. Integer(): while True: try: return int(raw_input()) except Value. Error: pass Slide #17

Check Input Syntax Is input in correct format? – Phone number (xxx-xxxx format) –

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

Python: Input Syntax Check import re def read. Phone. Number(): while True: phone =

Python: Input Syntax Check import re def read. Phone. Number(): 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 #19

Regular Expression Validation Beginnings and Endings 1. Begin with ^ to match beginning of

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

Input Entry Points 1. 2. 3. 4. 5. 6. Command line arguments Environment variables

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

Command Line Arguments Scripts access in different ways Python: argv, getopt class Ruby: ARGV,

Command Line Arguments Scripts access in different ways Python: argv, getopt class Ruby: ARGV, Option. Parser 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 #22

Dangerous Environment Variables PATH – Search path for binaries – Attacker puts directory with

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

Dangerous Environment Variables LD_PRELOAD – Programs loads functions from library specified in LD_PRELOAD before

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

Securing Your Environment Setting a Secure Environment in Shell Create a wrapper script that

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=“tn” Setting a Secure Environment in Ruby ENV = { PATH => “/bin: /usr/bin”, IFS => “ tn” } Slide #25

Unsigned Integers 0 7 000 111 6 1 001 110 011 101 5 2

Unsigned Integers 0 7 000 111 6 1 001 110 011 101 5 2 010 100 3 4 Slide #26

Java Factorial Program public static void main(String args[]) { long product = 1; for(int

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

Output 1! = 1 2! = 2 3! = 6 …. 20! = 2432902008176640000

Output 1! = 1 2! = 2 3! = 6 …. 20! = 2432902008176640000 21! = -4249290049419214848 Slide #28

Integer Overflows in Voting Broward County 2004 election Amendment 4 vote was reported as

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

Format Strings Formatted output functions use format language. – Percent(%) symbols in string indicate

Format Strings Formatted output functions use format language. – Percent(%) symbols in string indicate substitutions. – %[flags][width][. precision][length]specifier Example format specifiers – “%010 d”, 2009: 0000002009 – “%4. 2 f”, 3. 1415926: 3. 14 Example functions – printf() – scanf() – syslog() Slide #30

Format String Vulnerabilities User-specified format strings – userstring = “foo %x”; – printf( userstring

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

%n format command Number of characters written so far is stored into the integer

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

%n format attack Plan of Attack – Find address of variable to overwrite –

%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. , %. 64 x) Use %n to write anywhere in memory – Address on stack can point to any location Slide #33

Trust Relationships Relationship between multiple entities. – Assumptions that certain properties are true. •

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

Who do you trust? Client users – example: encryption key embedded in client Operating

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 19942001, only discovered when program made open source Slide #35

Trust is Transitive If you call another program, locally or across the network, you

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

Key Points 1. All input must be validated, using best technique possible: 1. 2.

Key Points 1. All input must be validated, using best technique possible: 1. 2. 3. Indirect Selection Whitelist Blacklist 2. Check input length, type, and syntax. 1. 2. Regular expressions are useful when used with anchors to whitelist input, but cannot validate languages like XML or JSON. To check URL or filesystem paths, programs must canonicalize them first to avoid path manipulation attacks. 3. Vulnerabilities 1. 2. 3. Command injection uses a shell called by program to run any command for the attacker. Integer overflows allow control of integer variable values. Format string attacks allow reading and writing of memory. Slide #37

References 1. 2. 3. 4. Brian Chess and Jacob West, Secure Programming with Static

References 1. 2. 3. 4. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. Goodrich and Tammasia, Introduction to Computer Security, Pearson, 2011. John Viega and Gary Mc. Graw, Building Secure Software, Addison-Wesley, 2002. David Wheeler, Secure Programming for UNIX and Linux HOWTO, http: //www. dwheeler. com/secureprograms/Secure-Programs-HOWTO/index. html, 2003. Slide #38