Secure Programming

CS 330 Secure Programming

Secure Programming

(slides from Prof. Dooley)

1


Source Material

• Some slides taken from a series of presentations by:

– Jedidiah R. Crandall, [email protected]

• Funded by the National Science Foundation Federal Cyber Service Scholarship For Service Program Grant No. 0113627 Distributed July 2002

• Embry-Riddle Aeronautical University • Prescott, Arizona • USA

• Bellovin, Steve, “Shifting the Odds: Writing (more) Secure Software,” 1996

• Bishop, Matt, “How Attackers Break Programs, and How to Write Programs More Securely,” 2002

2


More Source Material

• Wheeler, David, “Programming Secure Applications for Unix-like Systems,” 2003.

• Wheeler, David, “Secure Programming for Unix and Linux: HOWTO,” 2010. http://www.dwheeler.com/secure-programs/

• Chen, Hao, et. al., “Setuid Demystified,” USENIX Security Conference, 2002.

• Larochelle, D. and Evans, D., “Statically Detecting Likely Buffer Overflow Vulnerabilities,” USENIX Security Conference, 2001. Also at http://lclint.cs.virginia.edu

3

http://www.dwheeler.com/secure-programs/


More Source Material

• NCSA Secure Programming Guidelines at

http://archive.ncsa.uiuc.edu/General/Grid/ACES/security/p

rogramming/

• the rest by jfdooley 04/2005, 04/2011, 10/2012, 10/2016

• material from Pfleeger & Pfleeger,”Security in Computing,

3rd ed”, and Bishop, “Computer Security: Art and Science”

4

http://archive.ncsa.uiuc.edu/General/Grid/ACES/security/programming/

CS 330 Secure Programming 5


Agenda - 1

• Secure Programming

• Buffer Overflow - definitions & simple examples

• Unix - permissions, structures, & process execution

• How functions execute

– System. Stack and the Stack frame

– Parameter passing

– 32-bit vs 64-bit architecture


Agenda - 2

• Example - let’s get a program to create a shell

• Setuid programs

• C system calls

• Unix commands and tools

• The C compiler & the gdb debugger

• Writing our malware using gdb


Secure programming

• Software is buggy

• Bugs in security-sensitive software are often security holes

8


Secure programming

• Write your programs so that there are no places within them where an attacker can “gain a foothold” on a system through your program

9


Why are there security holes?

• Many programming languages aren’t ‘security conscious’• C and C++ in particular

– they allow direct access to memory locations– they allow arithmetic on memory addresses– they don’t automatically do static or dynamic bounds

checking on buffers– they are not type-safe!

10


No, really. Why are there holes?

• Development teams often don’t use checklists to spot this type of error

• Often testers don’t think of trying to make security holes like buffer overflows show up

• Modern software practice is somewhat sloppy, and security bugs get through

• And, lets face it, software is complicated and it’s easy to make mistakes in things that are only partially understood

11


Types of secure programming problems

• Buffer overflow

• Resource exhaustion

• Incomplete mediation (checking valid data)

• Time-of-check to time-of-use errors

• Other race conditions

• Numeric over/underflow

• Trust in general (users and privileges, environment variables, trusting other programs)

12

Secure Programming

Documents

Transcript of Secure Programming