Outline
Download
1 / 30

Outline - PowerPoint PPT Presentation


  • 132 Views
  • Uploaded on

Outline. Designing and Writing Secure Code General principles for architects/managers Example: sendmail vs qmail. General Principles. Compartmentalization Principle of least privilege Minimize trust relationships Defense in depth Use more than one security mechanism

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Outline' - zuriel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Outline
Outline

  • Designing and Writing Secure Code

    • General principles for architects/managers

    • Example: sendmail vs qmail


General principles
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
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
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 depth1

Check security

Check security

Secure resource with an ACL

Check security

Application.dll

Application.dll

Check security

Defense in Depth

Application.exe

[MSDN]


Secure the weakest link
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
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
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
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, …


Example mail transport agents
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
Simplified Mail Transactions

Mail User Agent

Mail Transport Agent

Mail Transport Agent

Mail User Agent

Mail Delivery Agent

Mail Delivery Agent

mbox

mbox

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

SMTP from network

from local

remote mailserver

tcpserver /

tcp-env / inetd

MUA

qmail-smtpd

qmail-inject

forwarded message

qmail-queue

qmail-system

qmail-send

qmail-rspawn

qmail-lspawn

qmail-remote

qmail-local

mbox / maildir /

program delivery

remote mailserver

to local


Structure of qmail
Structure of qmail

qmail-smtpd

qmail-inject

qmail-queue

Other incoming mail

Incoming SMTP mail

qmail-send

qmail-rspawn

qmail-lspawn

qmail-remote

qmail-local


Structure of qmail1
Structure of qmail

qmail-smtpd

qmail-inject

qmail-queue

  • Reads the message and creates an entry in the mail queue

  • Signals qmail-send

qmail-send

qmail-rspawn

qmail-lspawn

qmail-remote

qmail-local


Structure of qmail2
Structure of qmail

qmail-smtpd

qmail-inject

qmail-queue

  • qmail-send signals

    • qmail-lspawn if local

    • qmail-remote if remote

qmail-send

qmail-rspawn

qmail-lspawn

qmail-remote

qmail-local


Structure of qmail3
Structure of qmail

qmail-smtpd

qmail-inject

qmail-queue

qmail-send

qmail-lspawn

  • qmail-lspawn

    • Spawns qmail-local

    • qmail-local runs with ID of user receiving local mail

qmail-local


Structure of qmail4
Structure of qmail

qmail-smtpd

qmail-inject

qmail-queue

qmail-send

qmail-lspawn

  • qmail-local

    • Handles alias expansion

    • Delivers local mail

    • Calls qmail-queue if needed

qmail-local


Structure of qmail5
Structure of qmail

qmail-smtpd

qmail-inject

qmail-queue

qmail-send

qmail-rspawn

  • qmail-remote

    • Delivers message to remote MTA

qmail-remote


Least privilege in qmail
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
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
Least privilege

qmail-smtpd

qmail-inject

qmail-queue

setuid

qmail-send

qmail-rspawn

qmail-lspawn

root

qmail-remote

qmail-local


Keep it simple1
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
Security by Obscurity …

Is NOT Secure !!!

  • 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



Secure programming techniques an abstract view of program
Secure Programming Techniques: An Abstract View of Program

Program Component

  • Avoid buffer overflow

  • Secure software design

  • Language-specific problems

  • Application-specific issues

Respond judiciously

Validate input

Call other code carefully


Secure programming
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




ad