Secure Programming

1. Secure Programming Anawat (Tey) Kitthajaroenchai Branden Smith Team 41

2. General Principles • Secure programming refers to a set of code-writing practices intended to minimize the possibility of exploitation by an attacker • Most exploits occur as the result of execution conditions unforeseen by the programmer which can be contrived by an attacker in order to gain access to a system • “Stack-smashing” attacks, for example, typically take advantage of input storage routines which under certain conditions may overwrite the end of a storage buffer and write arbitrary data to the “return-to” address pointer for the function being executed ECE 4112 - Internetwork Security

3. General Principles • Least Privilege: enable as few privileges as possible to minimize the potential damage a successful attack on a program could do • If high privilege is initially required, surrender it as soon as possible • Modularize program and grant privileges only to modules which require them • Open Design: allow public scrutiny of program structure; do not depend on the obscurity of vulnerabilities • Limit usage of shared storage (such as temporary directories) to minimize risk that foreign data could enter the program • Maintain sharp separation between data and control; avoid allowing macro and script execution ECE 4112 - Internetwork Security

4. General Principles • Systems which maintain a set of users should never create default passwords or default superusers • These tend never to be removed or reset • If a program loads initialization values, ensure that those values are not stored in an area modifiable by untrusted users • Fail-safe defaults: In the event of program failure, program should stop processing any offending request and return to a secure failure state • This often does not mean complete shutdown, as in many cases to do so would open the door to trivial denial of service attacks • Shared resources should be locked during use to prevent untrusted programs from exploiting race conditions ECE 4112 - Internetwork Security

5. Validation of Input • Input from untrusted users can be used to spur unexpected behaviors, such as execution of user code, denial of service • Code which handles user input should be written to accept legal input and reject all else before passing the input on to system calls and other modules • This should not be done in reverse (write code to specifically reject certain invalid input, accept by default), as it is nearly impossible to enumerate all invalid cases • Common “invalid” inputs which could cause security flaws include empty strings, control characters (such as EOF, EoLn, ‘\0’, etc.), escape characters (‘\n’, ‘\r’, etc.) and extended ASCII characters (character values 128 - 255) ECE 4112 - Internetwork Security

6. Validation of Input • All URL/URIs must be validated, especially if they are to be used to direct subsequent flow of the program • Some URL schema (such as “javascript:”) are inherently insecure and should rarely be accepted as input • The application should check for substrings and internal characters which might have special meaning to the program or to the system • Delimiters (commas, spaces, newlines, tabs) • Control characters • the null-terminator ‘\0’ • depends heavily on the application being created; all apps which alter program flow based on “special inputs” recognize a different set of such input values ECE 4112 - Internetwork Security

7. Validation of Input • Command-line parameters must be validated before use • The first parameter is not always guaranteed to be the name of the program • It might be a good idea to disable globbing (use of the * wildcard) for filename/path inputs • Since globbing forces the use of additional CPU/disk resources, a long globbed path in some cases might be used to tie up system resources • It is also often a good idea not to accept “..” and “/” from filename inputs, as these might allow access to files to which the user should not have access ECE 4112 - Internetwork Security

8. Environment Variables • A program cannot be assured of the validity of the environment variables upon entry • Previous programs, user commands, and so forth may set environment variables to dangerous values, or may set duplicate variables to try to trick a program into verifying one value and using another • Not all environment variables are documented • Best idea is to eliminate all environment variables except the ones explicitly needed, then validate the values to which those are set • Done by manipulating the global array of character strings environ ECE 4112 - Internetwork Security

9. Buffer Overflows • Mostly covered by Lab Four, Aleph One’s article Smashing the Stack for Fun and Profit • If you cannot ensure by other means that they will not overrun the buffer bounds, replace the following functions as follows: • strcpy » » » strncpy • strcat » » » strncat • sprintf » » » snprintf • gets » » » fgets • Avoid strlen unless you know that a character string is null-terminated ECE 4112 - Internetwork Security

10. Buffer Overflows • Be aware of the possibility of negative values for size when reading input • If you assume this value is positive, you may mistakenly handle the string as though it were of very large positive size • Even if bounds checking is performed adequately, potential remains for security problems • For example: very long pathname string beginning with a number of ‘/’ characters sufficient to fill the buffer • If you use dynamic buffers, be sure that your programs fails safely when there is no more memory available ECE 4112 - Internetwork Security

11. Temporary Files • Be sure that all temporary files are created in a location not accessible to untrusted users • Avoid creating them in shared locations -- system cleanup of shared folders may make your program susceptible to race conditions • Use a randomized filename which cannot easily be guessed • One of the exercises for this lab involves the problems which arise from an attacker guessing a temporary filename • For the same reason, do not close temporary files then reuse the filenames of them ECE 4112 - Internetwork Security

12. External Resources and Libraries • Only use external resources which can be confirmed to be secure • Otherwise, re-implement the functionality in your code • Attackers might exploit the links between your code and dynamically linked libraries • One of the exercises in lab involves the manipulation of environment variables to surreptitiously load a “replacement” DLL • For secure applications, it is often best to compile programs statically, meaning to compile the binaries for the libraries directly into the main program • Be sure to validate parameters prior to passing them to an external library according to the restrictions relevant to the internal workings of that library ECE 4112 - Internetwork Security

13. Miscellaneous • gcc -Wall -Wpointer-arith -Wstrict-prototypes -W -pedantic -O2 -o output input.c • Do not use library random number generators for critical applications • Attackers with knowledge of the algorithm and the inputs to it may guess the random numbers • Use system calls such as mlock to prevent memory containing password information from being swapped to disk • Minimize direct feedback on errors to prevent attackers from learning the internal structure of the program • Use internal logs instead ECE 4112 - Internetwork Security

14. What you will do in lab • First exercise • Create a symbolic link pointing to sensitive information in the location where a program is known to create a temporary file • Second exercise • Use the LD_PRELOAD environment variable and a custom DLL to override the dynamic library used by a test program and execute custom code • Third exercise • Use the its4 system to scan C source code for security risks ECE 4112 - Internetwork Security