1. Chapter 11 Software Security 1

2. Many vulnerabilities result from poor programming practices Consequence from insufficient checking and validation of data and error codes o Awareness of these issues is a critical initial step in writing more secure program code

3. Software Security, Quality and Reliability Software quality and reliability: o Concerned with the accidental failure of program as a result of some theoretically random, unanticipated input, system interaction, or use of incorrect code o Improve using structured design and testing to identify and eliminate as many bugs as possible from a program o Concern is not how many bugs, but how often they are triggered Software security: o Attacker chooses probability distribution, specifically targeting bugs that result in a failure that can be exploited by the attacker o Triggered by inputs that differ dramatically from what is usually expected o Unlikely to be identified by common testing approaches 3

4. Defensive Programming Also referred to as secure programming Designing and implementing software so that it continues to function even when under attack Requires attention to all aspects of program execution, environment, and type of data it processes Software is able to detect erroneous conditions resulting from some attack Key rule is to never assume anything, check all assumptions and handle any possible error states 4

5. 5

6. Defensive Programming Programmers often make assumptions about the type of inputs a program will receive and the environment it executes in o Assumptions need to be validated by the program and all potential failures handled gracefully and safely Requires a changed mindset to traditional programming practices o Programmers have to understand how failures can occur and the steps needed to reduce the chance of them occurring in their programs 6

7. Security by Design Security and reliability are common design goals in most engineering disciplines Software Assurance Forum for Excellence in Code (SAFECode) o Develop publications outlining industry best practices for software assurance and providing practical advice for implementing proven methods for secure software development o http://www.safecode.org/ website provides free training materials http://www.safecode.org/ 7

8. Incorrect handling is a very common failing Input is any source of data from outside and whose value is not explicitly known by the programmer when the code was written Must identify all data sources Explicitly validate assumptions on size and type of values before use 8

9. Input Size & Buffer Overflow Programmers often make assumptions about the maximum expected size of input o Allocated buffer size is not confirmed o Resulting in buffer overflow Testing may not identify vulnerability o Test inputs are unlikely to include large enough inputs to trigger the overflow Safe coding treats all input as dangerous o Failure to validate input may result in an exploitable vulnerability 9

10. OpenSSL Heartbleed bug A recent example (2014) of a failure to check input validity TLS protocol involves establishing a connection (a session) between two entities A and B; when connection is idle, one entity can ask the other ‘Are you alive? If so, send me the 4 -letter word blah.’, as a heartbeat signal. Attacker asks a large number of bytes, say 40K letters, instead of 4 letters. The extra data are fetched from the server’s memory, due to the bug. It could include passwords and private keys, if the attacker is lucky. 10

11. 11 OpenSSL Heartbleed bug

12. Flaws relating to invalid handling of input data, specifically when program input data can accidentally or deliberately influence the flow of execution of the program Most often occur in scripting languages, e.g., Web CGI scripts 12

13. 13 Command injection attack In the CGI script, if attacker supplies input “xxx; echo attack success; ls -1 finger*”, then server executes “/usr/bin/finger –sh xxx; echo attack success; ls –l finger*”, and returns details of two files matching finger* Countermeasure is to add a test that ensures that the user input contains just alphanumeric characters. o ($user =~ /^\w+$/) means that the string $user should match (=~) a regular expression, any string that starts with (^) and ends with ($) only alphanumeric characters (\w+)

14. 14 This query works fine if the input $name = Bob ； but if the input is $name = Bob'; drop table suppliers, then the query becomes o SELECT * FROM suppliers WHERE name = ‘Bob‘; drop table suppliers; o The database views this line as 2 separate SQL statements: first select all entries with name Bob, then delete the entire supplier table. mysql_real_escape_string() prepends backslashes to the some special characters, including \n, \r, \, ', " o Query becomes SELECT * FROM suppliers WHERE name = ‘Bob\‘\; drop table suppliers’ o It looks for a database entry with name matching “Bob’; drop table suppliers”, and returns null. Or, perform input validation: o die "The specified name contains illegal characters!“ unless ($name =~ /^\w+$/); o But this does not handle the name O’Connor

15. A Cartoon 15

16. Another SQLi Attack <?php // We didn't check $_POST['password'], it could be anything the user wanted! For example: $_POST['username'] = 'aidan'; $_POST[‘password’] =''OR ‘1=1'; // Query database to check if there are any matching users $query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'"; mysql_query($query); // This means the query sent to MySQL would be this, and always return true, since the part after OR is ‘1=1', always TRUE. echo $query; ?> SELECT * FROM users WHERE user='aidan' AND password=''OR ‘1=1' 16 This attack can be prevented similarly by. mysql_real_escape_string(), or input validation

17. Validating Input Syntax It is necessary to ensure that data conform with any assumptions made about the data before subsequent use Input data should be compared against what is wanted Alternative is to compare the input data with known dangerous values By only accepting known safe data the program is more likely to remain secure 17

18. Additional concern when input data represents numeric values Internally stored in fixed sized value o 8, 16, 32, 64-bit integers o Floating point numbers depend on the processor used o Values may be signed or unsigned Must correctly interpret text form and process consistently o Have issues comparing signed to unsigned o Could be used to thwart buffer overflow check 18

19. Input Fuzzing Software testing technique that uses randomly generated data as inputs to a program o Range of inputs is very large o Intent is to determine if the program or function correctly handles abnormal inputs o Simple, free of assumptions, cheap o Assists with reliability as well as security Can also use templates to generate classes of known problematic inputs o Disadvantage is that bugs triggered by other forms of input would be missed Combination of approaches is needed for reasonably comprehensive coverage of the inputs 19

20. Writing Safe Program Code Second component is processing of data by some algorithm to solve required problem High-level languages are compiled and linked into machine code which is then directly executed by the target processor 20

21. Ensuring Machine Language Corresponds to Algorithm Issue is ignored by most programmers o Assumption is that the compiler or interpreter generates or executes code that validly implements the language statements o A malicious compiler could insert malicious instructions in the machine code Requires comparing machine code with original source o Slow and difficult Development of computer systems with very high assurance level is the one area where this level of checking is required o e.g., Common Criteria Evaluation Assurance Levels (EAL) 7 21

22. Correct Use of Memory Dynamic memory allocation may result in memory leaks o malloc() in C, new() in C++ o Steady reduction in memory available on the heap to the point where it is completely exhausted Java and C# provide automatic garbage collection o Prevents memory leaks 22

23. Operating System Interaction Programs execute on systems under the control of an operating system Environment variables should be considered external inputs to the program whose values need to be validated 23

24. Environment Variables Collection of string values inherited by each process from its parent o Can affect the way a running process behaves o e.g. variable PATH, which specifies the set of directories to search for any given command; IFS, which specifies the word boundaries in a shell script; and LD_LIBRARY_PATH, which specifies the list of directories to search for dynamically loadable libraries. All of these have been used to attack programs. Can be modified by the program process at any time o Modifications will be passed to its children Another source of untrusted program input Can be used to subvert a program that grants superuser privilege, in order to run code of the attacker’s selection with superuser privilege. 24

25. 25 This script in (a) takes the identity of some user, strips any domain specification if included, and then retrieves the mapping for that user to an IP address o The script in (a) calls two separate programs: sed and grep. If attacker redefines the PATH variable to include a directory they control, which contains a program called grep, then his program is called. o (The regular expression ‘s/@.*$//’ means that: find the pattern @ followed by any number of characters until end of string, and replace them with empty string, i.e., user@example.com will be converted to user.) The script in (b) eliminates the attack in (a), but is vulnerable for another reason. o The IFS (Internal Field Separator) variable is used to separate the words that form a line of commands. It defaults to a space, tab, or newline character. However, it can be set to any sequence of characters. Consider the effect of including the “=” character in this set. Then the assignment of a new value to the PATH variable is interpreted as a command to execute the program PATH with the list of directories as its argument. If the attacker has also changed the PATH variable to include a directory with an attack program PATH, then this will be executed when the script is run. o The script is now running an executable program named “PATH”, with an input argument “/sbin:/bin:/usr/sbin:/usr/bin”. Suppose the program named “PATH” happens to be “rm –rf”, and the process running the script has root privileges, then it will delete some important folders.

26. Dynamically linked libraries may be vulnerable to manipulation of LD_LIBRARY_PATH Used to locate suitable dynamic library The attacker can construct a custom version of a common library, placing the desired attack code in a function known to be used by some target, dynamically linked program. Then by setting the LD_LIBRARY_PATH variable to reference the attacker’s copy of the library first, when the target program is run and calls the known function, the attacker’s code is run with the privileges of the target program. To prevent it, either statically link privileged libraries, or prevent use of LD_LIBRARY_PATH 26

27. Privilege escalation Exploit of flaws may give attacker greater privileges Least privilege Run programs with least privilege needed to complete their function Determine appropriate user and group privileges required Decide whether to grant extra user or just group privileges Ensure that privileged program can modify only those files and directories necessary 27

28. Programs with root/ administrator privileges are a major target of attackers Often privilege is only needed at start Good design partitions complex programs in smaller modules with needed privileges They provide highest levels of system access and control Are needed to manage access to protected system resources Can then run as normal user Provides a greater degree of isolation between the components Reduces the consequences of a security breach in one component Easier to test and verify 28

29. Many programs use temporary files in common, shared system area (/tmp in Linux) File name must be unique, not accessed by others Commonly create name using process ID o Unique, but predictable Attack example on the “tripwire” file integrity program o Attacker writes a script that made repeated guesses on the temporary filename used by tripwire and create a symbolic link from that name to the password file. But attacker does not have root privilege, so he cannot write to the password file. o The tripwire program runs with root privileges, giving it access to all files on the system. o Attacker might guess and attempt to create own file between another program checking the file does not exist and subsequently creating it. o If the attacker succeeds, then tripwire will follow the link and use the password file as its temporary file, destroying all user login details and denying access to the system until the administrators can replace the password file with a backup copy. 29

30. 30 Secure temporary file creation requires the use of a random temporary filename. string tempnam ( string dir, string prefix ) o Create a temporary file with random name in a shared directory on Linux and UNIX systems.

31. Summary Handling program input o Input size and buffer overflow o Validating input syntax o Input fuzzing Interacting with the operating system and other programs o Environment variables o Using least privileges o Safe temporary file use Software security issues o Introducing software security and defensive programming Writing safe program code o Correct algorithm implementation o Ensuring that machine language corresponds to algorithm o Correct interpretation of data values o Correct use of memory 31