CMSC 414 Computer and Network Security Lecture 24

1
CMSC 414Computer and Network SecurityLecture 24

• Jonathan Katz

2
Application-level security
3
Application-level security

• I.e., programming-language security
• Previous focus was on protocols and algorithms to
  prevent attacks
• Are they implemented correctly?
• Here, focus is on programming errors and how to
  deal with them
• Reducing/eliminating/finding errors
• Containing damage resulting from errors

4
Classifying flaws

• Intentional flaws
• E.g., backdoors
• Unintentional flaws
• E.g., programmer errors

5
Buffer overflows

• 50 of reported vulnerabilities
• Overflowing a buffer results in data written
  elsewhere
• Users data space/program area
• System data/program code
• Including the stack, or memory heap
• Can also occur in other contexts
• E.g., parameters passed via URL

6
Example

• Suppose a web server contains a function void
  func(char str) char buf128
• strcpy(buf, str)
  do-something(buf)
• When the function is invoked the stack looks
  like
• What if str is 136 bytes long?

7
Basic exploit

• Suppose stack looks like
• When func() exits, user will be given a
  shell !!
• Note attack code runs in stack

(exact shell code by Aleph One)
8
Finding buffer overflows

• Hackers find buffer overflows as follows
• Run web server on local machine
• Issue requests with long tags. All long tags end
  with
• If web server crashes search core dump for
  to find overflow location.

9
Incomplete mediation

• E.g., changing symbolic link between checking and
  use
• E.g., parameters passed via URL
• Parameters may be checked at client-side
• but checking still necessary server-side
• E.g., changing prices in URL

10
Cross-site scripting

• Violation of privacy
• General rule always check inputs from untrusted
  source!

11
Time-to-check vs. time-of-use

• Serialization/synchronization flaw
• E.g., presenting command then changing command
  while it is being verified

12
Covert channels

• Intentionally inserted by programmers into
  software, to later leak information
• Examples in booke.g., spacing information in
  printed page, formats, etc.
• Other examples file lock channel,
  existence/non-existence of file, etc.

13
Analysis of covert channels

• Shared resource matrix
• Tabulates subjects and the resources thave have
  access to
• Information flow analysis (in source code)
• E.g., B A supports info. flow from A to B
• If (D 1) then B A supports info. flow from
  D to B also!
• Trace information flow throughout program

14
Timing attacks

• Password checking routines
• Web caching

15
Finding/preventing flaws
16
Penetration testing?

• Limited to finding/patching existing flaws
• Cannot be used to guarantee that software is free
  of all flaws
• Patching flaws in this way has its own problems
• Narrows focus to fixing a specific flaw, rather
  than addressing issues more broadly
• May introduce new flaws

17
Automated testing

• Successful to some extent
• Hard to catch all flaws
• Traditional program verification/testing focuses
  on what a program should do
• Here, we are concerned with things a program
  should not do

18
Techniques for preventing flaws

• Secure programming
• Developmental controls
• Better techniques
• Secure programming languages
• Static analysis
• Secure compilation
• Dynamic analysis
• Software fault isolation

19
Techniques

• Inferring trust
• Source authentication/code signing
• Proof-carrying code
• OS controls
• Sandboxing
• System-call interposition techniques
• Secure boot of OS

20
Developmental controls

• Modularity
• Improves ability to locate flaws
• Easier to verify/fix code
• Encapsulation/information hiding
• Peer review/testing/analysis
• Automated code testing

21
Secure programming techniques (Based on
Programming Secure Applications for Unix-Like
Systems, David Wheeler)
22
Overview

• Validate all input
• Avoid buffer overflows
• Program internals
• Careful calls to other resources
• Send info back intelligently