DOC PREVIEW
Stanford CS 155 - Designing and Writing Secure Application Code

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Designing and Writing Secure Application CodeJohn MitchellOutlineGeneral principles• Least privilege, defense in depth, …Example• Sendmail vs qmailTools for secure coding• Type-safe programming languages• Purify• Perl tainting• Code analysis algorithms• Run-time monitoring (another lecture)General topics in this courseVulnerabilities• How hackers break into systems– Circumvent security mechanisms (e.g., dictionary attack)– Use code for purpose it was not intended (buffer overflow)Defensive programming• Build all software with security in mind• Make sure video game is not a boot loaderSecurity Mechanisms• Authentication• Access control• Network protocolsThis lectureBefore you start building …What are the security requirements?• Confidentiality (secrets remain secret)• Integrity (meaning preserved)• Availability• AccountabilityWhat threats are possible?Who do you trust / not trust?Security = preserve properties against attackGeneral adviceCompartmentalization• 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 informativeCompartmentalization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 needs2Compartmentalization (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 codeExample: .NETclass NativeMethods{// This is a call to unmanaged code. Executing this method requires // the UnmanagedCode security permission. Without this permission,// an attempt to call this method will throw a SecurityException:[DllImport("msvcrt.dll")]public static extern int puts(string str);[DllImport("msvcrt.dll")]internal static extern int _flushall();}Code denies permission not needed[SecurityPermission(SecurityAction.Deny, Flags = SecurityPermissionFlag.UnmanagedCode)]private static void MethodToDoSomething(){ try{ Console.WriteLine(“ … ");SomeOtherClass.method();}catch (SecurityException){…}}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 • SSH + Tripwire Fail securely• Many, many vulnerabilities are related to error handling, debugging or testing features, error messages 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 mattersKeep 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 code3Promote 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• Security by obscurity doesn’t work!!!Don’t reinvent the wheelConsult expertsAllow public review Use software, designs that other have usedExamples• Bad use of crypto: 802.11b• Protocols without expert review: 802.11i• Use standard url parser, crypto library, good random number generater, …Example: Mail Transport AgentsSendmail• Complicated system• Source of many vulnerabilitiesQmail• Simpler system designed with security in mind• Gaining popularityQmail was written by Dan Bernstein, starting 1995$500 reward for successful attack; no one has collectedMarket share17%42%20029%47%200155%200063%199876%199780%1996QmailSendmailYearSimplified Mail Transactionsmbox mboxMail User AgentMail Delivery AgentMail Delivery AgentMail Transport AgentMail Transport AgentMail 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 MTAStanford Sendmail VulnerabilitySent: Tuesday, March 04, 2003 1:12 PMTo: [email protected]: Stanford ITSS Security Alert: sendmail Header Processing Vulnerabilitysendmail is the most popular Mail Transfer Agent (MTA) program in use on the Internet, …sendmail contains an error in one of the security checks it employs on addresses in its headers, which may allow an attacker to execute malicious code within the sendmail security context, usually root… All users of sendmail should patch immediately …4Example: qmailLeast privilege• Each module uses least privileges necessary• Only one setuid program– setuid to one of the other qmail user IDs, not root– No setuid root binaries• Only one run as root– Spawns the local delivery program under the UID and GID of the user being delivered to– No delivery to root– Always changes effective uid to recipient before running user-specified programOther secure coding ideasStructure of qmailqmail-smtpdqmail-localqmail-remoteqmail-lspawnqmail-rspawnqmail-sendqmail-injectqmail-queueIncoming SMTP mailOther incoming mailStructure of qmailqmail-smtpdqmail-localqmail-remoteqmail-lspawnqmail-rspawnqmail-sendqmail-injectqmail-queue Splits mail msg into 3 files• Message contents• 2 copies of header,


View Full Document

Stanford CS 155 - Designing and Writing Secure Application Code

Documents in this Course
Lecture 5

Lecture 5

64 pages

Phishing

Phishing

31 pages

Load more
Download Designing and Writing Secure Application Code
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Designing and Writing Secure Application Code and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Designing and Writing Secure Application Code 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?