Announcement Project 2 Due Project 3 will be out this weekend.

Slides:



Advertisements
Similar presentations
Communications of the ACM (CACM), Vol. 32, No. 6, June 1989
Advertisements

Outline Designing and Writing Secure Code –General principles –Example: sendmail vs qmail Compiler Prime: Run-time Environment and Program Organization.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Draft-lemonade-imap-submit-01.txt “Forward without Download” Allow IMAP client to include previously- received message (or parts) in or as new message.
Outline Designing and Writing Secure Code –General principles for architects/managers –Example: sendmail vs qmail (optional in backup slides) Buffer Overflow.
VM: Chapter 5 Guiding Principles for Software Security.
Secure Design Principles  secure the weakest link  reduce the attack surface  practice defense in depth  minimize privilege  compartmentalize  fail.
19.1 Silberschatz, Galvin and Gagne ©2003 Operating System Concepts with Java Chapter 19: Security The Security Problem Authentication Program Threats.
System and Network Security Practices COEN 351 E-Commerce Security.
It’s always better live. MSDN Events Security Best Practices Part 2 of 2 Reducing Vulnerabilities using Visual Studio 2008.
Outline Designing and Writing Secure Code
Yan Chen Dept. of Computer Science Northwestern University Information Security Curriculum Development in Northwestern.
Tcl Agent : A flexible and secure mobile-agent system Paper by Robert S. Gray Dartmouth College Presented by Vipul Sawhney University of Pennsylvania.
1 Security and Software Engineering Steven M. Bellovin AT&T Labs – Research
Outline Designing and Writing Secure Code –General principles for architects/managers –Example: sendmail vs qmail Compiler Prime: Run-time Environment.
C. Edward Chow Presented by Mousa Alhazzazi C. Edward Chow Presented by Mousa Alhazzazi Design Principles for Secure.
Secure Architecture Principles Isolation and Least Privilege
Efficient Instruction Set Randomization Using Software Dynamic Translation Michael Crane Wei Hu.
Designing Security In Web Applications Andrew Tomkowiak 10/8/2013 UW-Platteville Software Engineering Department
Stack Management Each process/thread has two stacks  Kernel stack  User stack Stack pointer changes when exiting/entering the kernel Q: Why is this necessary?
11 SECURING INTERNET MESSAGING Chapter 9. Chapter 9: SECURING INTERNET MESSAGING2 CHAPTER OBJECTIVES  Explain basic concepts of Internet messaging. 
John Mitchell Secure OS Principles and Security Policies by John Mitchell (Modified by Vijay Ganesh)
Web Application Access to Databases. Logistics Test 2: May 1 st (24 hours) Extra office hours: Friday 2:30 – 4:00 pm Tuesday May 5 th – you can review.
ISQS server attacks Presented by Deven Patel.
Csci5233 Computer Security1 Bishop: Chapter 27 System Security.
CMSC 414 Computer (and Network) Security Lecture 14 Jonathan Katz.
SECURITY ZONES. Security Zones  A security zone is a logical grouping of resources, such as systems, networks, or processes, that are similar in the.
1 Version 3.0 Module 11 TCP Application and Transport.
| nectar.org.au NECTAR TRAINING Module 5 The Research Cloud Lifecycle.
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
Postfix Mail Server Postfix is used frequently and handle thousands of messages. compatible with sendmail at command level. high performance program easier-
1 Electronic Messaging Module - Electronic Messaging ♦ Overview Electronic messaging helps you exchange messages with other computer users anywhere in.
Week 10-11c Attacks and Malware III. Remote Control Facility distinguishes a bot from a worm distinguishes a bot from a worm worm propagates itself and.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
Privilege separation in Condor Bruce Beckles University of Cambridge Computing Service.
CIS 450 – Network Security Chapter 4 - Spoofing. Definition - To fool. In networking, the term is used to describe a variety of ways in which hardware.
Linux Security. Authors:- Advanced Linux Programming by Mark Mitchell, Jeffrey Oldham, and Alex Samuel, of CodeSourcery LLC published by New Riders Publishing.
Security CS Introduction to Operating Systems.
John Mitchell Announcement Thursday lecture: Alex Stamos, Yahoo! VP of Information Security (CISO) – Alex has been busy with Heartbleed – He is taking.
LinxChix And Exim. Mail agents MUA = Mail User Agent Interacts directly with the end user  Pine, MH, Elm, mutt, mail, Eudora, Marcel, Mailstrom,
Lecture 13 Page 1 CS 236 Online Principles for Secure Software Following these doesn’t guarantee security But they touch on the most commonly seen security.
SMTP Tapu Ahmed Jeremy Nunn. Basics Responsible for electronic mail delivery. Responsible for electronic mail delivery. Simple ASCII protocol that runs.
| nectar.org.au NECTAR TRAINING Module 5 The Research Cloud Lifecycle.
Security Architecture of qmail and Postfix Authors: Munawar Hafiz Ralph E. Johnson Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar.
Engineering Secure Software. Key Principles  Principle of Least privilege  Defense in Depth  Obviously No Vulnerabilities (vs. No Obvious)  i.e. Assume.
Design Principles and Common Security Related Programming Problems
Linux Operations and Administration Chapter Twelve Configuring a Mail Server.
Designing and Writing Secure Application Code John Mitchell.
Draft-lemonade-imap-submit-00.txt “Forward without Download” Allow IMAP client to include previously- received message (or parts) in or as new message.
June 1, 2004© Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Introduction to Computer Programming Concepts M. Uyguroğlu R. Uyguroğlu.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
Software Security Q: What does it mean to say that a program is secure? A: There is a sufficient amount of trust that the program maintains _____________,
Lecture 14 Page 1 CS 236 Online Secure Programming CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Developing a Secure Internet Service SE Linux in Production Russell Coker Linux Consultant.
SE-1021 Software Engineering II
Protecting Memory What is there to protect in memory?
Security+ All-In-One Edition Chapter 1 – General Security Concepts
Protecting Memory What is there to protect in memory?
Protecting Memory What is there to protect in memory?
CIW Lesson 7 Part A Name: _______________________________________
Access Control and Operating System Security
Distrustful Decomposition
Announcement Project 2 Due Project 3 will be out this weekend.
Chapter 29: Program Security
Distrustful Decomposition
Operating System Concepts
 Zone in name space  DNS IN THE INTERNET  Generic domains :There are fourteen generic domains, each specifying an organization type.
Preventing Privilege Escalation
Presentation transcript:

Announcement Project 2 Due Project 3 will be out this weekend

Designing and Writing Secure Code

Outline General principles –Least privilege, defense in depth, … Buffer Overflow Example –Sendmail vs qmail Tools for secure coding –Type-safe programming languages –Code analysis algorithms –Run-time monitoring

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 Keep it simple Consult experts –Don’t build what you can easily borrow/steal –Open review is effective and informative

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

Compartmentalization (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 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

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

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

Security by Obscurity … Hiding sensitive information is hard 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 Is NOT Secure !!!

Don’t reinvent the wheel Consult experts Allow public review Use software, designs that other have used Examples –Bad use of crypto: b –Protocols without expert review: i –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 popularity Qmail was written by Dan Bernstein, starting 1995 $500 reward for successful attack; no one has collected

Simplified Mail Transactions mbox Mail User Agent Mail Delivery 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-smtpdqmail-inject qmail-queue qmail-send qmail-rspawn qmail-remote qmail-lspawn qmail-local mbox / maildir / program delivery MUA remote mailserver SMTP from networkfrom 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 Splits mail msg into 3 files –Message contents –2 copies of header, etc. 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 three groups: qmaild, qmailr, qmails –Except one as root Only one run as root (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

Least privilege qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue root setuid

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 Setuid to the user ID of the qmail queue owner, not root No setuid root binaries 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.

UIDs qmail-smtpd qmail-localqmail-remote qmail-lspawnqmail-rspawn qmail-send qmail-inject qmail-queue root setuid qmailduser qmails qmailr root user setuid user qmail-start root inetd root Start qmail- send & queue management

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 “Write bug-free code” (DJB) Small code is more secure –Plug in interposing modules rather than complicating the core code

Comparison LinesWordsCharsFiles qmail sendmail zmailer-2.2e smail exim

Comparison with other MTAs MTAMaturitySecurityFeaturesPerform ance Modular QmailMediumHigh Yes SendmailHighLowHighLowNo PostfixMediumHighMediumHighYes

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 judiciously 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

Backup Slides