CMSC 426/626: Secure Coding

Krishna M. Sivalingam

Sources: From Secure Coding, Mark and van Wyk, O’Reilly,

2003www.cert.org/secure-coding

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

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

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

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

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.

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”

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

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

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 WebCrispin Cowan’s SANS 2000 Talk on Web

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.

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

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

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 */

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

Source: Bishop and Dilger’s 1996 paper in

Computing Systems

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!

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

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)

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

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:

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

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

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

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

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

To be Continued