1. Announcement
Project 2 Due
Project 3 will be out this weekend

2. Designing and Writing Secure Code

3. Outline General principles Buffer Overflow Example
Least privilege, defense in depth, …
Buffer Overflow
Example
Sendmail vs qmail
Tools for secure coding
Type-safe programming languages
Code analysis algorithms
Run-time monitoring

4. General Principles Compartmentalization Defense in depth
Principle of least privilege
Minimize trust relationships
Defense in depth
Use more than one security mechanism
Secure the weakest link
Fail securely
Keep it simple
Consult experts
Don’t build what you can easily borrow/steal
Open review is effective and informative

5. Compartmentalization
Divide system into modules
Each module serves a specific purpose
Assign different access rights to different modules
Read/write access to files
Read user or network input
Execute privileged instructions (e.g., Unix root)
Principle of least privilege
Give each module only the rights it needs

6. Compartmentalization (II)
Example
Sendmail runs as root
Root privilege needed to bind port 25
No longer needed after port bind established
But most systems keep running as root
Root privileges needed later to write to user mailboxes
Will look at qmail for better security design
Minimize trust relationships
Clients, servers should not trust each other
Both can get hacked
Trusted code should not call untrusted code

7. Defense in Depth Failure is unavoidable – plan for it
Have a series of defenses
If an error or attack is not caught by one mechanism, it should be caught by another
Examples
Firewall + network intrusion detection
Fail securely
Many, many vulnerabilities are related to error handling, debugging or testing features, error messages

8. Secure the weakest link
Think about possible attacks
How would someone try to attack this?
What would they want to accomplish?
Find weakest link(s)
Crypto library is probably pretty good
Is there a way to work around crypto?
Data stored in encrypted form; where is key stored?
Main point
Do security analysis of the whole system
Spend your time where it matters

9. Keep It Simple Use standard, tested components
Don’t implement your own cryptography
Don’t add unnecessary features
Extra functionality  more ways to attack
Use simple algorithms that are easy to verify
A trick that may save a few instructions may
Make it harder to get the code right
Make it harder to modify and maintain code

10. Security by Obscurity …
Is NOT Secure !!!
Hiding sensitive information is hard
Information in compiled binaries can be found
Reverse engineering
Disassembler: machine code to assembly
Discomplier: machine code to high-level language
Insider attacks are common
Firewalls do not protect against inside attacks

11. Don’t reinvent the wheel
Consult experts
Allow public review
Use software, designs that other have used
Examples
Bad use of crypto: b
Protocols without expert review: i
Use standard url parser, crypto library, good random number generater, …

12. Example: Mail Transport Agents
Sendmail
Complicated system
Source of many vulnerabilities
Qmail
Simpler system designed with security in mind
Gaining popularity
Qmail was written by Dan Bernstein, starting 1995
$500 reward for successful attack; no one has collected

13. Simplified Mail Transactions
Mail User Agent
Mail Transport Agent
Mail Transport Agent
Mail User Agent
Mail Delivery Agent
Mail Delivery Agent
mbox
mbox
procmail is a popular Message Delivery Agent (MDA). The function of an MDA is to accept a message from the MTA for a specific user or mailbox, and deliver the message according to the user's desires. procmail can be used to "filter" messages by the content of various header fields or the body of the message. For example, messages from a particular person can be directed to a mailbox for just that person.
Message composed using an MUA
MUA gives message to MTA for delivery
If local, the MTA gives it to the local MDA
If remote, transfer to another MTA

14. Example: Qmail Compartmentalize Nine separate modules
If one module compromised, others not
Move separate functions into mutually untrusting programs
Always validate input from other modules

15. THE BIG Qmail PICTURE SMTP from network from local remote mailserver
tcpserver /
tcp-env / inetd
MUA
qmail-smtpd
qmail-inject
forwarded message
qmail-queue
qmail-system
qmail-send
qmail-rspawn
qmail-lspawn
qmail-remote
qmail-local
mbox / maildir /
program delivery
remote mailserver
to local

16. Structure of qmail qmail-smtpd qmail-inject qmail-queue
Other incoming mail
Incoming SMTP mail
qmail-send
qmail-rspawn
qmail-lspawn
qmail-remote
qmail-local

17. Structure of qmail qmail-smtpd qmail-inject qmail-queue
Splits mail msg into 3 files
Message contents
2 copies of header, etc.
Signals qmail-send
qmail-send
qmail-rspawn
qmail-lspawn
qmail-remote
qmail-local

18. Structure of qmail qmail-smtpd qmail-inject qmail-queue
qmail-send signals
qmail-lspawn if local
qmail-remote if remote
qmail-send
qmail-rspawn
qmail-lspawn
qmail-remote
qmail-local

19. Structure of qmail qmail-smtpd qmail-inject qmail-queue qmail-send
qmail-lspawn
qmail-lspawn
Spawns qmail-local
qmail-local runs with ID of user receiving local mail
qmail-local

20. Structure of qmail qmail-smtpd qmail-inject qmail-queue qmail-send
qmail-lspawn
qmail-local
Handles alias expansion
Delivers local mail
Calls qmail-queue if needed
qmail-local

21. Structure of qmail qmail-smtpd qmail-inject qmail-queue qmail-send
qmail-rspawn
qmail-remote
Delivers message to remote MTA
qmail-remote

22. Least Privilege in Qmail
Each module uses least privileges necessary
Each runs under different non-privileged UID in three groups: qmaild, qmailr, qmails
Except one as root
Only one run as root (except qmail-start)
Spawns the local delivery program under the UID and GID of the user being delivered to
Always changes effective uid to recipient before running user-specified program

23. Least privilege setuid root qmail-smtpd qmail-inject qmail-queue
qmail-send
Qmail-inject() and qmail-smtpd() call the qmail-quue() function
qmail-rspawn
qmail-lspawn
root
qmail-remote
qmail-local

24. Principles, sendmail vs qmail
Do as little as possible in setuid programs
Of 20 recent sendmail security holes, 11 worked only because the entire sendmail system is setuid
Only qmail-queue is setuid
Its only function is add a new message to the queue
Setuid to the user ID of the qmail queue owner, not root
No setuid root binaries
Do as little as possible as root
The entire sendmail system runs as root
Operating system protection has no effect
Only qmail-start and qmail-lspawn run as root.

25. UIDs setuid root qmail-start qmail-smtpd qmail-inject qmail-queue
inetd
Start qmail-send &
queue management
qmaild
user
qmail-smtpd
qmail-inject
qmail-queue
qmails
setuid
qmail-send
qmailr
qmails
root
inetd <networking, tool> Berkeley daemon program that listens for connection requests or messages for certain ports and starts server programs to perform the services associated with those ports. Sometimes known as netd.
qmail-rspawn
qmail-lspawn
root
setuid user
qmailr
user
qmail-remote
qmail-local

26. Keep it simple Parsing Libraries Small code is more secure
Limited parsing of strings
Minimizes risk of security holes from configuration errors
Modules do parsing are isolated and run with user privilege
Libraries
Avoid standard C library, stdio
“Write bug-free code” (DJB)
Small code is more secure
Plug in interposing modules rather than complicating the core code

27. Comparison Lines Words Chars Files qmail-1.01 16028 44331 370123 288
sendmail-8.8.8
52830
179608 53
zmailer-2.2e10
57595
205524
227
smail-3.2
62331
246140
151
exim-1.90
67778
272084
127

28. Comparison with other MTAs
Maturity
Security
Features
Perform ance
Modular
Qmail
Medium
High
Yes
Sendmail
Low No
Postfix

29. Secure Programming Techniques: An Abstract View of Program
Program Component
Avoid buffer overflow
Secure software design
Language-specific problems
Application-specific issues
Respond judiciously
Validate input
Call other code carefully

30. Secure Programming Validate all your inputs Avoid buffer overflow
Command line inputs, environment variables, CGI inputs, …
Don't just reject “bad” input, define “good” and reject all else
Avoid buffer overflow
Carefully call out to other resources
Check all system calls and return values

31. Backup Slides