OutlineGeneral PrinciplesCompartmentalizationDefense in DepthSlide 5Secure the weakest linkPromote PrivacyKeep It SimpleDon’t reinvent the wheelSlide 10Preventing Buffer Overflow AttacksSome unsafe C lib functionsPreventing buf overflow attacksMarking stack as non-executeStatic source code analysisRun time checking: StackGuardCanary TypesStackGuard (Cont.)End of Quarter ReviewThread One: AttacksThread Two: Integrated DefenseEmerging Landscape and Topics Upon RequestsBackup SlidesExample: Mail Transport AgentsSimplified Mail TransactionsExample: QmailSlide 27Structure of qmailSlide 29Slide 30Slide 31Slide 32Slide 33Least Privilege in QmailPrinciples, sendmail vs qmailLeast privilegeKeep it simpleSecurity by Obscurity …Secure Programming Techniques: An Abstract View of ProgramSecure ProgrammingComparisonComparison with other MTAsOutline•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 AttacksGeneral 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 informativeHave 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 codeDefense 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 securelyDefense in DepthCheck securityCheck securityApplication.dllApplication.exeCheck securityCheck securitySecure resource with an ACLApplication.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 mattersPromote 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 commonKeep 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 codeDon’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 AttacksPreventing Buffer Overflow AttacksSome unsafe C lib functionsstrcpy (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 optimizationsStatic 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.strretsfplocaltopofstackcanarystrretsfplocalcanaryFrame 1Frame 2Canary 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
View Full Document
Unlocking...