CMSC 426/626: Secure Coding

1. CMSC 426/626: Secure Coding Krishna M. Sivalingam Sources: From Secure Coding, Mark and van Wyk, O’Reilly, 2003 www.cert.org/secure-coding

2. Where can errors occur? During entire software lifecycle • Security Architecture/Design stage • Man-in-the-middle attack • Race condition attack • Replay attack • Implementation Stage • Buffer overflow attack • Parsing error attack • Back door attacks (aka Trapdoors) • Code Maintenance Stage

3. Flaw Classifications • Landwehr’s Scheme • Bishop’s Scheme • Aslam’s Scheme • Du/Mathur’s classification • Flaws are Intentional and Inadvertent • Inadvertent Flaw Classifications • Validation Error • Domain Error • Serialization and Aliasing • Inadequate Authentication and Identification • Boundary Condition Violation • Other exploitable logic error

4. Study of Buffer Overflow Attack • Cowan, Crispin, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole. "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade." Proceedings of DARPA Information Survivability Conference and Expo (DISCEX), 1999 • http://insecure.org/stf/mudge_buffer_overflow_tutorial.html

5. Buffer Overflows • Inject attack code by overflowing the buffer • Usually involves adding code based on target machines’ CPU opcodes • Execute code with all the privileges of the vulnerable program • Thus, if program is running as root, attacker can run at will any code as root • Typically, manage to invoke execve /bin/sh or similar to get a root shell

6. Program Segments • An executing program consists of: • Code • Initialized Data • Global variables • Stack • Heap (for dynamic allocation) • Remember that local variables, return address, etc. are stored in the stack when a function is invoked • When a local variable is over-run, it can alter return address, etc.

7. Where to Inject Code • On the stack (automatic variables) • On the heap (malloc or calloc variables) • In static data areas • Executable code need not be restricted to the overflowing buffer – code can be injected elsewhere • One can also use existing code • For example, if exec(arg) exists in program, modify running code by making arg point to “/bin/sh”

8. Jump to Attacker’s Code • Activation Record • Overflow into return address on the stack and make it point at the code. • Function pointers • Overflow into “void (*foo())()” and it point at the code • Setjmp and longjmp commands, that are used for checkpointing and recovery • Alter address given to longjmp to point to attacker’s code

9. Buffer Overflow Details • Look at Mudge’s sample buffer overflow attack

10. Buffer Overflow Defenses • Writing Correct Code • Vulnerable programs continue to emerge on a regular basis • C has many error-prone idioms and a culture that favors performance over correctness. • Static Analysis Tools • Fortify – looks for vulnerable constructs • Too many false positives From Crispin Cowan’s SANS 2000 Talk on Web

11. Buffer Overflow Defenses • Non-executable buffers • Non executable data segments • Optimizing compiles emit code into program data segments • Non executable stack segments • Highly effective against code injection on the stack but not against code injections on the heap or static variables.

12. Buffer Overflow Defenses • Array Bound Checking • Can run 12x-30x slower • a[3] is checked but *(a+3) is not • Type safe languages: Java or ML • There are millions of lines of C code in operating systems and security system applications • Attack the Java Virtual Machine which is a C program • StackGuard program: Adds a “canary” value, which is a 32-bit random # or a known string terminator (CR, LF, ‘\0’, etc.) • Compiler adds canary and system can check for this value at runtime • Entire RedHat system has been recompiled with this and shown to be less vulnerable

13. Race Conditions • http://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf • http://citeseer.ist.psu.edu/bishop96checking.html • http://www.mirrors.wiretapped.net/security/development/secure-programming/bishop-dilger-1996-checking-for-race-conditions-in-file-accesses.pdf

14. Race condition: What is it? • Consider a setuid program, owned by root • UserA is presently executing the program, hence is running it as root • Assume that the program wants to write to a file. The system must check whether UserA has the right privileges on this file, checked as follows: if (access(filename, W_OK) == 0){ if ((fd = open(filename, O_WRONLY)) == NULL){ perror(filename); return(0); } /* now write to the file */

15. Race condition: What is it? • In the time between verifying access and opening the file, if the file referred to changes, then its access will not have been checked • Called TOCTTOU (Time-of-check-To-Time-of-Use) binding flaw • For example, if access is originally checked on /tmp/X AND before execution of write statement: • /tmp/X is deleted AND • Hard link from /etc/passwd is created to /tmp/X • Then, process will write to /etc/passwd! • Present in xterm program, while logging sessions

16. Source: Bishop and Dilger’s 1996 paper in Computing Systems

17. Race conditions, contd. • Similar attack possible on binmail program • Binmail appends mail to an existing mail spool file • E.g. /usr/spool/mail/jkl • Binmail verifies if file exists (and is not a symbolic link) • Before binmail writes to file, jkl is deleted AND made a hard link to /etc/passwd • Now, binmail appends data to /etc/passwd • Attacker can create a new account with no password and root privileges • Note that binding flaws do not arise when file descriptors are used!

18. Good Practices in Implementation • Inform Yourself • Follow Vulnerability Discussions and Alerts (eg. www.cert.org) • Read books and papers on secure coding practices, analyses of software flaws, etc. • Explore open source software • Examples of how to and how not to write code

19. Good Practices in Implementation • Handle Data with Caution • Cleanse data: Examine input data for malicious intent (altering character sets, using dis-allowed characters) • Perform bounds checking • Check array indices • Check configuration files • Can be modified by attacker • Check command-line parameters • Don’t trust web URLs and parameters within • Be careful of web content (variables hidden in HTML fields)

20. Good Practices in Implementation • Check web cookies • Check environment variables • Set valid initial values for data • Understand filename references and use them correctly • Check for indirect file references (e.g. Shortcuts, symbolic links) • Be careful of how program and data files are located (as in searching using PATH variable) • Reuse “Good” Code whenever Practical

21. Good Practices in Implementation • Sound Review Processes • Perform Peer review of Code • Perform Independent Validation and Verification • Use automated security tools • Static Code checkers • RATS - Rough Auditing Tool for Security • SPLINT – Source code scanner http://splint.org/ • Uno: http://spinroot.com/uno/ • Runtime checkers • Libsafe: http://directory.fsf.org/libsafe.html • PurifyPlus: http://www-306.ibm.com/software/awdtools/purifyplus/ • Immunix Tools:

22. Good Practices in Implementation • Profiling Tools • Papillon for Solaris: http://www.roqe.org/papillon/ • Gprof from GNU • Janus – policy enforcement and profiling; http://www.cs.berkeley.edu/~daw/janus/ • Black-box Testing for Fault-Injection Tools • Appscan: http://www.watchfire.com/securityzone/default.aspx • Whisker: wiretrip.net • ISS Database Scanner: http://www.iss.net/ • Perform network-based vulnerability scans • Nmap: http://insecure.org/nmap/ • Nessus: http://www.nessus.org/ • ISS Internet Scanner

23. Good Practices in Implementation • Make Generous Use of Checklists • Security checklists must be created and checked against. For example: • Application requires password for access • All user ID logins are unique • Uses role-based access control • Encryption is used • Code should be Maintainable • Practice standards of in-line documentation • Remove obsolete code • Test all code changes

24. Implementation, Don’ts • Don’t write code that uses relative filenames • Fully qualified filenames should be used • Don’t refer to a file twice in the same program by its name • Always use file descriptors after initial open • Prevents “race condition attack” that exploit time between access check and file execution • Don’t invoke untrusted programs from within trusted ones • Avoid using setuid or similar mechanisms whenever possible • Don’t assume that users are not malicious

25. Implementation, Don’ts • Don’t dump core – code must fail gracefully • Coredump can be used to extract valuable data stored in memory during execution • Don’t assume that a system call (or any function call) is always successful – always check for return values and error variable values • Computer-based random number generators are “pseudo-random” and can have repitition • Don’t invoke shell or command line from within a program • Don’t use world writable storage, even for temporary files

26. Implementation, Don’ts • Don’t trust user-writable storage not to be tampered with • Don’t keep sensitive data in a database without password protection • Don’t code usernames/passwords into an application • Don’t echo passwords! • Don’t rely on host-level file protection mechanisms • Don’t make access decisions based on environment variables or command-line arguments • Don’t issue passwords via email

27. To be Continued