Upload
osborn-doyle
View
218
Download
0
Embed Size (px)
Citation preview
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
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
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