Outline• Designing and Writing Secure Code

– General principles for architects/managers

– Example: sendmail vs qmail (optional in backup slides)

• Buffer Overflow Attacks• Defense for Buffer Overflow Attacks

General Principles• Compartmentalization

– Principle of least privilege

– Minimize trust relationships

• Defense in depth

– Use more than one security mechanism

– Secure the weakest link

– Fail securely

• Promote privacy

• Keep it simple

• Consult experts

– Don’t build what you can easily borrow/steal

– Open review is effective and informative

Have you applied them in your design / evaluation?

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

• Minimize trust relationships

– Clients, servers should not trust each other

• Both can get hacked

– Trusted code should not call untrusted code

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

– Ensure that you handle errors

– Do not expose system internals even in case of errors

• Stack traces, internal errors, ... shown to clients

– Test if your system fails securely

Defense in Depth

Check security

Check security

Application.dll

Application.exe

Check security

Check security

Secure resource with an ACL

Application.dll

[MSDN]

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

Promote Privacy

• Discard information when no longer needed

– No one can attack system to get information

• Examples

– Don’t keep log of old session keys

– Delete firewall logs

– Don’t run unnecessary services (fingerd)

• Hiding sensitive information is hard

– Information in compiled binaries can be found

– Insider attacks are common

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

Don’t reinvent the wheel• Consult experts

• Allow public review

• Use software, designs that others have used

• Examples

– Bad use of crypto: 802.11b

– Protocols without expert review: early 802.11i

– Use standard url parser, crypto library, good random number generator, …

Outline• Designing and Writing Secure Code

– General principles for architects/managers

– Example: sendmail vs qmail (optional in backup slides)

• Buffer Overflow Attacks• Defense for Buffer Overflow Attacks

Preventing Buffer Overflow Attacks

Some unsafe C lib functions

strcpy (char *dest, const char *src)

strcat (char *dest, const char *src)

gets (char *s)

scanf ( const char *format, … )

printf (conts char *format, … )

Preventing buf overflow attacks• Main problem:

– strcpy(), strcat(), sprintf() have no range checking.

– Use “safe” versions strncpy(), strncat() very carefully

• Defenses:

– Type safe languages (Java, ML). Legacy code?

– Mark stack as non-execute.

– Static source code analysis.

– Run time checking: StackGuard, Libsafe, SafeC, (Purify).

– Black box testing (e.g. eEye Retina, ISIC ).

Marking stack as non-execute• Basic stack exploit can be prevented by marking

stack segment as non-executable

– Code patches exist for Linux and Solaris.

• Problems:

– Some apps need executable stack (e.g. LISP interpreters).

– Does not block more general overflow exploits:• Overflow on heap: overflow buffer next to func pointer.

• Cannot make all the data segment non-executable

• More recent UNIX and MS windows emit dynamic code into program data for performance optimizations

Static source code analysis• Statically check source to detect buffer overflows.

– Several consulting companies.

• Several tools exist to automate the review process:

– Stanford: Engler, et al. Test trust inconsistency.

– @stake.com (l0pht.com): SLINT (designed for UNIX)

– Berkeley: Wagner, et al. Test constraint violations.

• Find lots of bugs, but not all.

Run time checking: StackGuard• Many many run-time checking techniques …

• Solution: StackGuard (WireX)

– Run time tests for stack integrity.

– Enhance the code generator for emitting code to set up and tear down functions

– Embeds “canaries” in stack frames and verify their integrity prior to function return.

strretsfplocaltopof

stackcanarystrretsfplocal canary

Frame 1Frame 2

Canary Types• Random canary: (used in Visual Studio 2003)

– Choose random string at program startup.

– Insert canary string into every stack frame.

– Verify canary before returning from function.

– To corrupt random canary, attacker must learn current random string.

• Terminator canary:Canary = 0 (null), newline, linefeed, EOF

– String functions will not copy beyond terminator.

– Hence, attacker cannot use string functions to corrupt stack.

StackGuard (Cont.)

• StackGuard implemented as a GCC patch.

– Program must be recompiled.

• Minimal performance effects

– Worst case: 8% for Apache.

End of Quarter Review• Cryptography

– Symmetric encryption case study: DES/AES algorithms

– Asymmetric encryption case study: RSA

– One-way hash function and message digests: MD5, SHA1, SHA2

• Authentications

– Authentication mechanisms: password authentication, challenge-response authentication protocols, biometrics, token-based authentication

– Trusted Intermediary

• Symmetric crypto: KDC and Kerberos

• Asymmetric crypto: CA and certificates in SSL/TLS

Thread One: Attacks• Viruses, worms, and botnets (C&C)

– Scan for open ports/services

– Send exploits for vulnerabilities of the discovered services

– Tools: nmap, nessus, and hydra (homework 8)

• Web attacks and defense

– XSS (CSRF)

– SQL injection

• DoS attacks and defense

– SYN flooding attacks

Thread Two: Integrated Defense• IDS/IPS and monitoring

– Host based

– Network based

– Snort

• Firewalls

– Stateless/Stateful Packet filters

– Application-level Proxy

• Other variants

– Network Access Control (Cisco guest lecture)

– Wireless authentication: WEP vs. WPA

Cisco Security Agent

Cisco IPS

Cisco Firewall

Cisco NAC

CS MARS

Emerging Landscape and Topics Upon Requests

• Cloud Security

• Software Security

– Buffer overflow attacks and defense

Backup Slides

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

Simplified Mail Transactions

mbox mbox

Mail User Agent

Mail Delivery Agent

Mail Delivery Agent

Mail Transport

Agent

Mail Transport

Agent

Mail User Agent

• 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

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

THE BIG Qmail PICTURE

tcpserver /tcp-env / inetd

qmail-smtpd qmail-inject

qmail-queue

qmail-send

qmail-rspawn

qmail-remote

qmail-lspawn

qmail-local

mbox / maildir /program delivery

MUA

remote mailserver

remote mailserver

SMTP from network from local

to local

qmail-system

forwarded message

Structure of qmail

qmail-smtpd

qmail-localqmail-remote

qmail-lspawnqmail-rspawn

qmail-send

qmail-inject

qmail-queue

Incoming SMTP mail Other incoming mail

Structure of qmail

qmail-smtpd

qmail-localqmail-remote

qmail-lspawnqmail-rspawn

qmail-send

qmail-inject

qmail-queue• Reads the message and

creates an entry in the mail queue

• Signals qmail-send

Structure of qmail

qmail-smtpd

qmail-localqmail-remote

qmail-lspawnqmail-rspawn

qmail-send

qmail-inject

qmail-queue• qmail-send signals

– qmail-lspawn if local

– qmail-remote if remote

Structure of qmail

qmail-smtpd

qmail-local

qmail-lspawn

qmail-send

qmail-inject

qmail-queue

• qmail-lspawn

– Spawns qmail-local

– qmail-local runs with ID of user receiving local mail

Structure of qmail

qmail-smtpd

qmail-local

qmail-lspawn

qmail-send

qmail-inject

qmail-queue

• qmail-local

– Handles alias expansion

– Delivers local mail

– Calls qmail-queue if needed

Structure of qmail

qmail-smtpd

qmail-remote

qmail-rspawn

qmail-send

qmail-inject

qmail-queue

• qmail-remote

– Delivers message to remote MTA

Least Privilege in Qmail• Each module uses least privileges necessary

• Each runs under different non-privileged UID in four groups: qmaild, qmailr, qmails, and qmailq

– Except one as root

• Only one run as root: qmail-lspawn (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

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

• 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.

Least privilege

qmail-smtpd

qmail-localqmail-remote

qmail-lspawnqmail-rspawn

qmail-send

qmail-inject

qmail-queue

root

setuid

Keep it simple• Parsing

– 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

• Small code is more secure

– Plug in interposing modules rather than complicating the core code

Security by Obscurity …

• 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

• Assume an attacker knows everything you know

• Why?

– If attacker has 1-in-a-million chance, and there are a million attackers, you are out of luck

Is NOT Secure !!!

Secure Programming Techniques: An Abstract View of

Program

• Avoid buffer overflow• Secure software design• Language-specific problems• Application-specific issues

Program Component

Validate input Respond judiciousl

y

Call other code

carefully

Secure Programming• Validate all your inputs

– 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

Comparison

Lines Words Chars Files

qmail-1.01 16028 44331 370123 288

sendmail-8.8.8 52830 179608 1218116 53

zmailer-2.2e10 57595 205524 1423624 227

smail-3.2 62331 246140 1701112 151

exim-1.90 67778 272084 2092351 127

Comparison with other MTAs

MTA Maturity Security Features

Performance

Modular

Qmail Medium High High High Yes

Sendmail

High Low High Low No

Postfix Medium High Medium High Yes