Designing and Writing Secure Application Code Outline General
Total Page:16
File Type:pdf, Size:1020Kb
Outline Designing and Writing General principles Secure Application Code • Least privilege, defense in depth, … Example • Sendmail vs qmail John Mitchell Tools for secure coding • Type-safe programming languages • Purify • Perl tainting • Code analysis algorithms • Run-time monitoring (another lecture) General topics in this course Before you start building … Vulnerabilities What are the security requirements? • How hackers break into systems • Confidentiality (secrets remain secret) – Circumvent security mechanisms (e.g., dictionary attack) • Integrity (meaning preserved) – Use code for purpose it was not intended (buffer overflow) • Availability Defensive programming • Accountability • Build all software with security in mind This What threats are possible? • Make sure video game is not a boot loader lecture Who do you trust / not trust? Security Mechanisms • Authentication • Access control Security = preserve properties against attack • Network protocols General advice Compartmentalization Compartmentalization Divide system into modules • Principle of least privilege • Each module serves a specific purpose • Minimize trust relationships • Assign different access rights to different modules Defense in depth – Read/write access to files • Use more than one security mechanism – Read user or network input • Secure the weakest link – Execute privileged instructions (e.g., Unix root) • Fail securely Principle of least privilege Keep it simple • Give each module only the rights it needs Consult experts • Don’t build what you can easily borrow/steal • Open review is effective and informative 1 Compartmentalization (II) Example: .NET Example class NativeMethods { • Sendmail runs as root // This is a call to unmanaged code. Executing this method requires – Root privilege needed to bind port 25 // the UnmanagedCode security permission. Without this permission, – No longer needed after port bind established // an attempt to call this method will throw a SecurityException: • But most systems keep running as root [DllImport("msvcrt.dll")] – Root privileges needed later to write to user mailboxes public static extern int puts(string str); • Will look at qmail for better security design [DllImport("msvcrt.dll")] Minimize trust relationships internal static extern int _flushall(); • Clients, servers should not trust each other } – Both can get hacked • Trusted code should not call untrusted code Code denies permission not needed Defense in Depth [SecurityPermission(SecurityAction.Deny, Flags = Failure is unavoidable – plan for it SecurityPermissionFlag.UnmanagedCode)] Have a series of defenses private static void MethodToDoSomething() • If an error or attack is not caught by one { try mechanism, it should be caught by another { Console.WriteLine(“ … "); Examples SomeOtherClass.method(); • Firewall + network intrusion detection } • SSH + Tripwire catch (SecurityException) Fail securely { • Many, many vulnerabilities are related to error … handling, debugging or testing features, error } messages } Secure the weakest link Keep It Simple Think about possible attacks Use standard, tested components • How would someone try to attack this? • Don’t implement your own cryptography • What would they want to accomplish? Don’t add unnecessary features Find weakest link(s) • Extra functionality ⇒ more ways to attack • Crypto library is probably pretty good Use simple algorithms that are easy to verify • Is there a way to work around crypto? • A trick that may save a few instructions may – Data stored in encrypted form; where is key stored? – Make it harder to get the code right Main point – Make it harder to modify and maintain code • Do security analysis of the whole system • Spend your time where it matters 2 Promote Privacy Don’t reinvent the wheel Discard information when no longer needed Consult experts • No one can attack system to get information Allow public review Examples Use software, designs that other have used • Don’t keep log of old session keys • Delete firewall logs • Don’t run unnecessary services (fingerd) Examples Hiding sensitive information is hard • Bad use of crypto: 802.11b • Information in compiled binaries can be found • Protocols without expert review: 802.11i • Insider attacks are common • Use standard url parser, crypto library, good • Security by obscurity doesn’t work!!! random number generater, … Example: Mail Transport Agents Market share Sendmail Year Sendmail Qmail • Complicated system • Source of many vulnerabilities 1996 80% Qmail 1997 76% • Simpler system designed with security in mind 1998 63% • Gaining popularity 2000 55% 2001 47% 9% 2002 42% 17% Qmail was written by Dan Bernstein, starting 1995 $500 reward for successful attack; no one has collected Simplified Mail Transactions Stanford Sendmail Vulnerability Sent: Tuesday, March 04, 2003 1:12 PM Mail Mail To: [email protected] Mail User Mail User Transport Transport Agent Agent Subject: Stanford ITSS Security Alert: sendmail Header Agent Agent Processing Vulnerability sendmail is the most popular Mail Transfer Agent (MTA) Mail Mail program in use on the Internet, … mbox Delivery Delivery mbox Agent Agent sendmail contains an error in one of the security checks it employs on addresses in its headers, which may allow an Message composed using an MUA attacker to execute malicious code within the sendmail security context, usually root… MUA gives message to MTA for delivery • If local, the MTA gives it to the local MDA All users of sendmail should patch immediately … • If remote, transfer to another MTA 3 Example: qmail Structure of qmail Least privilege qmail-smtpd qmail-inject • Each module uses least privileges necessary • Only one setuid program qmail-queue – setuid to one of the other qmail user IDs, not root Incoming SMTP mail Other incoming mail – No setuid root binaries • Only one run as root qmail-send – Spawns the local delivery program under the UID and GID of the user being delivered to – No delivery to root qmail-rspawn qmail-lspawn – Always changes effective uid to recipient before running user-specified program Other secure coding ideas qmail-remote qmail-local Structure of qmail Structure of qmail qmail-smtpd qmail-inject qmail-smtpd qmail-inject qmail-queue qmail-queue Splits mail msg into 3 files qmail-send signals • Message contents • qmail-lspawn if local • 2 copies of header, etc. • qmail-remote if remote qmail-send qmail-send Signals qmail-send qmail-rspawn qmail-lspawn qmail-rspawn qmail-lspawn qmail-remote qmail-local qmail-remote qmail-local Structure of qmail Structure of qmail qmail-smtpd qmail-inject qmail-smtpd qmail-inject qmail-queue qmail-queue qmail-send qmail-send qmail-lspawn qmail-lspawn qmail-lspawn qmail-local • Spawns qmail-local • Handles alias expansion • qmail-local runs with ID of • Delivers local mail user receiving local mail • Calls qmail-queue if needed qmail-local qmail-local 4 Structure of qmail Least privilege qmail-smtpd qmail-inject qmail-smtpd qmail-inject qmail-queue qmail-queue setuid qmail-send qmail-send qmail-rspawn qmail-rspawn qmail-lspawn root qmail-remote • Delivers message to remote MTA qmail-remote qmail-remote qmail-local qmailq – user who is allowed to read/write mail queue UIDs Principles, sendmail vs qmail qmaild user Do as little as possible in setuid programs qmail-smtpd qmailq qmail-inject • Of 20 recent sendmail security holes, 11 worked qmail-queue only because the entire sendmail system is setuid setuid • Only qmail-queue is setuid – Its only function is add a new message to the queue qmail-send Do as little as possible as root qmailr qmails root • The entire sendmail system runs as root qmail-rspawn qmail-lspawn root – Operating system protection has no effect • Only qmail-start and qmail-lspawn run as root. setuid user qmailr user qmail-remote qmail-local Principles, sendmail vs qmail Keep it simple Programs and files are not addresses Parsing • sendmail treats programs and files as addresses • Limited parsing of strings – “sendmail goes through horrendous contortions trying to – Minimizes risk of security holes from configuration errors keep track of whether a local user was responsible for an address. This has proven to be an unmitigated disaster” Libraries (DJB) • Avoid standard C library, stdio • qmail programs and files are not addresses – “Write bug-free code” (DJB) – “The local delivery agent, qmail-local, can run programs Don’t repeat functionality or write to files as directed by ~user/.qmail, but it's always running as that user. Security impact: .qmail, like • One simple mechanism handles forwarding, .cshrc and .exrc and various other files, means that aliasing, and mailing lists (instead of 3) anyone who can write arbitrary files as a user can • Single delivery mode instead of a selection execute arbitrary programs as that user. That's it.” (DJB) 5 Comparison Additional general advice [Wheeler] Program Component Lines Words Chars Files qmail-1.01 16028 44331 370123 288 • Avoid buffer overflow • Secure software design sendmail-8.8.8 52830 179608 1218116 53 Validate input Respond • Language-specific problems judiciously zmailer-2.2e10 57595 205524 1423624 227 • Application-specific issues smail-3.2 62331 246140 1701112 151 Call other code exim-1.90 67778 272084 2092351 127 carefully See Wheeler’s book on web Summary from [Wheeler] Additional reading Validate all your inputs Contents • Command line inputs, environment variables, CGI inputs, … • Contemporary security • Don't just reject “bad” input, define “good” and reject all else – Need for secure systems,