Lecture 27: Secure Coding - PowerPoint PPT Presentation

About This Presentation

Title:

Lecture 27: Secure Coding

Description:

Lecture 27: Secure Coding & Wrap Up – PowerPoint PPT presentation

Number of Views:232

Avg rating:3.0/5.0

Slides: 58

Provided by: Sims155

Category:

more less

Transcript and Presenter's Notes

Title: Lecture 27: Secure Coding

1
Lecture 27 Secure Coding Wrap Up
2
Saltzer Schroeder Seven Design Principles

Least Privilege
Economy of Mechanism
Complete Mediation
Open design
Separation of privilege
Least Common Mechanism
Psychological acceptability

3
1988 Morris Internet Worm

fingerd.c
char line512
line0 \0
gets(line)
Results in 6,000 computers being infected.

4
Fingerd bug fix

line0 \0
gets(line)
Becomes
memset(line,0,sizeof(line))
fgets(line,sizeof(line),stdin)

5
Miller, Fredrickson So

1990, An Empirical Study of the Reliability of
Unix Utilities
1995, Fuzz Revisited
2000, Windows NT Fuzz Report

6
1990 Fuzz Findings

Between 25 and 33 of Unix utilities crashed or
hung by supplying them with unexpected inputs
End-of-file in the middle of an input line
Extra-long input
Letters for numbers, etc.
In one case, the entire computer crashed.

7
1995 Fuzz Revisited

Vendors not overly concerned about bugs in their
programs
Many of the bugs discovered (approximately 40)
and reported in 1990 are still present in their
exact form in 1995.
Code was made freely available via anonymous FTP
Exact random data streams used in testing were
made available
2000 copies of the tools were downloaded from FTP
It is difficult to understand why a vendor would
not partake of a free and easy source of
reliability improvements

8
1995 Fuzz Revisited, cont.

Lowest failure rates wee for the Free Software
Foundations GNU utilities (7)
FSF had strict coding rules that forbid the use
of fixed-length buffers.
Many X clients would readily crash when fed
random streams of data

9
2000 Fuzz against NT

45 of all programs expecting user input could be
crashed
100 of Win32 programs could be crashed with
Win32 messages
LRESULT CALLBACK
w32_wnd_proc (hwnd, msg, wParam, lParam)
. . .
POINT pos
pos (POINT )lParam
. . .
if (TrackPopupMenu((HMENU)wParam,
flags, pos-gtx, pos-gty, 0, hwnd,
NULL))
. . .

10
Fuzz Today

eEye Digital Security does network fuzz testing
http//www.eeye.com/
Most remote crashes can be turned into remote
exploits
Retina Vulnerability Scanner

11
Morris Worm II

Exploited Sendmails WIZ and DEBUG commands
Cracked passwords
Caused havoc by hyper-replication (common
problem)

12
Avoiding Security-Related Bugs

Avoid bugs in general
Test with non-standard input
Look for back doors
(theoretically impossible to do perfectly)

13
Design Principles

Carefully design the program before you start.
Remember you will either design it before you
start writing it, or while you are writing it.
But you will design it.
Document your program before writing the code.
Make critical portions of the program as small as
possible.
Resist adding new features. The less code you
write, the less likely you are to introduce new
bugs.

14
Design Principles 2

Resist rewriting standard functions. (Even when
standard libraries have bugs.)
Be aware of race conditions
Deadlock conditions More than one copy of your
program may be running at the same time!
Sequence conditions Your code does not execute
automatically!
Do not stat() then open()
Do not use access()
Write for clarity and correctness before
optimizing.

15
Coding Standards

Check all input arguments. Always.
Check arguments you pass to system calls

16
Return Codes

Check all system call returns.
fd open(filename,O_RDONLY) can fail!
read(fd,buf,sizeof(buf)) can fail
close(fd) can fail!
Use perror(open) or err(1,open failed) to
tell the user why something failed.
Log important failures with syslog()

17
File Names

Always use full pathnames
Check all user-supplied input (filenames) for
shell metacharacters
If you are expecting to create a new file, open
with O_EXCLO_CREAT to fail if the file exists.
If you are expecting an old file, open with
O_EXCL to fail if it does not exist.

18
Temporary Files

Use tmpfile() or mkstemp() to create temporary
files
FILE ftmpfile(void)
int fd mkstemps(char template, int
suffixlen)
Never use mktemp() or tmpnam()

19
Functions to avoid
Avoid Use instead
gets() fgets()
strcpy() strncpy()
strcat() strncat()
sprintf() snprintf()
vsprintf() vsnprintf()
20
Coding Standards 2

Check arguments passed to program via environment
variables
e.g., HOME, PAGER, etc.
Do bounds checking on every variable.
If a variable should be 0..5, make sure it is not
-5 or 32767
Check lengths before you copy.

21
Coding Standards

Use assert() within your program.
j index(buf,)
assert(jgt0)

22
Coding Standards

Avoid C functions that use statically-allocated
buffers
These are the rules for multi-threaded coding as
well!
dont use
struct tm
localtime(const time_t clock)
Use
struct tm
localtime_r(const time_t clock,
struct tm result)

23
Logging

Design your logs to be parsed by a computer
Using syslog() if possible.
Include a heartbeat log

24
RFC 1750 Randomness Recommendations

Keep seeds for RNGs secret!
Dont seed with
Time of day
Serial number
Ethernet address
Beware using
Network timing
Random selections from databases
Use
Analog input devices (/dev/audio)
Never use rand()

25
Passwords

Store the hash of passwords and a salt, not the
passwords themselves
Also store
Date password was changed
of invalid password attempts
Location of invalid password attempt
Dont restrict password character set
Try flipping password case (just to be nice)

26
Limit Privilege

Limit access to the file system
chroot() and jail() under Unix
Restrict use of C compiler

27
Programs that need privilege (SUID/SGID/Admin)

Dont do it. Most of the time, its not
necessary (Wood Kochan, Unix System Security,
1985)
Dont use root or Administrator privs when you
can create a specialty group.
Use permissions as early as possible to open
files, etc., then give up the privs.
Avoid embedding general-purpose command
languages, interfaces, etc., in programs that
require privilege
Erase execution environment (PATH, etc.) and
build from scratch
Use full path names

28
Tips for Network Programs

Do reverse lookups on all connections
Include load shedding or load limiting
Include reasonable timeouts
Make no assumptions about content of input data
Make no assumption about the amount of input
Call authd if possible --- but dont trust the
results

29
More Network Tips

Use SSL if at all possible.
Include support for using a proxy
Build in graceful shutdown
From signals
From closed network pipes
Include self recognition so that more than one
copy of the server doesnt run at the same time.
Try not to create a new network protocol
Dont hard-code port numbers
Dont trust privileged ports, IP source
addresses
Dont send passwords in clear text.

30
Web-based Applications

Validate all information from the client
Dont trust the content of HIDDEN fields
Verify Cookies
Digitally sign or MAC all information
Use prepared SQL statements
Never sprintf(s,select where
usernames,username)
Always select where username?

31
Programming Languages

Avoid C, C if possible
Use perls tainting feature (-T)
Be careful with Javas class loader
Be careful with eval()
perl
python
shell

32
Things to avoid

Dont provide shell escapes in interactive
programs
Be very careful with system() and popen() calls
Do not create files in world-writable directories
Use setrlimit() to avoid dumping core

33
Before you Finish

Read though your code
How would you attack your own code?
What happens if it gets unexpected inputs?
What happens if you place a delay between system
calls?
Test your assumptions
Run by root. Run by nobody
Run in a different directory
What is /tmp or /tmp/root doesnt exist?

34
Testing

Test with a testing tool
tcov (SVR4)
gcov (GNU)
Commercial Testing tools
CodeCenter
PurifyPlus

35
More testing

Stress Test
Low memory
Filled disk
Test Missing DLLs
Internet Explorer fails open if msrating.dll is
not installed
Monitor all reads writes
Holodeck (Windows)
dtrace (Solaris)

36
Code Review

Walk through your code with another competent
programmer
Simply putting your code on the Internet is not
the same as having it reviewed!

37
Famous Open-Source Problems

Kerberos random number generator
Sendmail DEBUG and WIZ
fingerd
Others (from class)
Hylafax program
NNTPcache

38
Class Wrap Up
39
What did we learn?

Security by itself is a meaningless concept.
What is being secured?
Who or what is it being secured from?
What are the other tradeoffs that security
decisions are forcing?

40
Security is not a goal in itself

Cant secure everything
Security perimeter
Secure against specific attacks
Secure systems must be usable as well
Security to the exclusion of other goals isnt
useful either

41
Security and Privacy Policy

Need to have a written policy for
What users/customers are allowed to do
What is expected from users
What organization is allowed to do
Policy is informed by
Law
Local practice
Custom

42
Security and Usability Policy

Swat boxes dont work
Eternal Vigilance is hard
Better to have a system that allows you to ask
for forgiveness
Undo as a security principle
Doesnt work well for all users.

43
Fair Information Practices

1. There must be no personal data record-keeping
systems whose very existence is secret.
2. There must be a way for a person to find out
what information about the person is in a record
and how it is used.
3. There must be a way for a person to prevent
information about the person that was obtained
for one purpose from being used or made available
for other purposes without the person's consent.
4. There must be a way for a person to correct or
amend a record of identifiable information about
the person.
5. Any organization creating, maintaining, using,
or disseminating records of identifiable personal
data must assure the reliability of the data for
their intended use and must take precautions to
prevent misuses of the data. HEW 73