chapter 6 implementation security n.
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 6 Implementation Security PowerPoint Presentation
Download Presentation
Chapter 6 Implementation Security

Loading in 2 Seconds...

play fullscreen
1 / 65

Chapter 6 Implementation Security - PowerPoint PPT Presentation

  • Uploaded on

Chapter 6 Implementation Security. Sue Fitzgerald Metropolitan State University CS 328 Computer Security Fall 2008. Overview. Computer security threats related to code Unintentional: Buggy implementations Faulty installation and/or configuration Software not used as intended

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

Chapter 6 Implementation Security

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
chapter 6 implementation security

Chapter 6 Implementation Security

Sue Fitzgerald

Metropolitan State University

CS 328 Computer Security Fall 2008

  • Computer security threats related to code
    • Unintentional:
      • Buggy implementations
      • Faulty installation and/or configuration
      • Software not used as intended
    • Intentional (malicious code):
      • Trojan horses
      • Trap doors
      • Viruses
      • Worms
common security programming mistakes
Common Security/Programming Mistakes
  • Buffer overflow
  • Integer overflow
  • Other malicious inputs
  • Race conditions
  • Malware
  • Insecure programming languages
  • Insecure software development life cycle
buffer overflows
Buffer Overflows
  • Oldest, most common vulnerability
  • Program stack provides temporary working space for the running program

int add(int A1, int A2) {

int L1, L2; /* local variables L1, L2 */

L1 = A1 + A2;

return(L1); /* return value */


int main() {

x = add(10,20);


stack frames cont
Stack Frames (cont)
  • A stack frame contains:
    • Arguments
    • Return address of next instruction to execute upon return from subroutine
    • Saved registers
    • Local variables
stack frames cont1
Stack Frames (cont)
  • The main routine calls add:
    • add’s arguments are first pushed onto the stack
    • the return address (the next instruction in main to execute after add finishes) is pushed
    • control is transferred to add
stack frames cont2
Stack Frames (cont)
  • add’s stack frame :
a buffer overflow
A Buffer Overflow

int copy(char *s) /* subroutine “copy” */


char buffer[10]; /* local variable*/



int main() /* main program */


char name[]=”ABCDEFGHIJKLMNOPQR”; /* 18 chars */

add(name); /* call to subroutine “add” */



a buffer overflow continued
A Buffer Overflow (continued)
  • copy’s stack frame after prologue:
a buffer overflow continued1
A Buffer Overflow (continued)
  • Stack after execution of copy (but before the return):
a buffer overflow continued2
A Buffer Overflow (continued)
  • The string overflowed copy’s buffer:
    • It overwrote the return address with ‘OPQR’ (0x4F505152)
  • When copy finishes, control will be transferred to the instruction at address 0x4F505152 - error!
  • The Morris worm sent a specially crafted 243-byte string to the finger daemon:
    • Overflowed a buffer and overwrote the return address
    • The fingerd executedthe /bin/sh program which executed the grappling hook code


when does buffer overflow occur
When Does Buffer Overflow Occur?
  • Code accepts input from user, remote program, another procedure
  • Procedure does not check inputs
  • Input is longer than buffer
  • C# and Java throw a runtime exception
  • C does not – assumes strings end with zero – and keeps on copying
  • Problems with strcpy() and gets()
  • Text segment – where program instructions go
  • Data segment – where global variables and data whose size is known at compile time go
  • Heap – where dynamic data structures go
  • Libraries – previously compiled, standard code linked into programs
  • Stack - space for temporary variables associated with current procedure
stack smashing
Stack Smashing
  • Classic buffer overflows inject code directly into the stack, then ‘return’ to that code instead of the calling procedure
  • The code runs with the victim’s process identity and privileges
  • Traditionally called ‘shellcode’
stack smashing continued
Stack Smashing (continued)
  • return-to-libc attack
    • Injected return address returns to a library function (such as system()) with nasty fake arguments
  • Instead of overwriting the return address, the stack overflow could replace (or view) important data instead
structure of the exploit
Structure of the Exploit
  • Replace the return address by copying the bogus return address into many locations on the stack via a buffer overflow
  • Payload – bad instructions, also loaded as part of the buffer overflow
structure of the exploit continued
Structure of the Exploit (continued)
  • NOP sled – pad the buffer with NOPs in case the return address is close but not 100% accurate; slide down the NOPS to the bad code
  • Injected code cannot contain a zero – since this is interpreted as the end of the string
heap smashing
Heap Smashing
  • Same as stack smashing except buffer overflow occurs in the heap (dynamic data structures) rather than the stack
  • Heaps are organized into blocks with data structure linking information in the header of each block
  • Header information is overwritten
  • Design operating system to prevent code from executing from the stack
  • Still leaves the heap vulnerable
  • Make writable pages non-executable – if a program can write to that part of memory, that part of memory cannot be used to store and run code
  • Still leaves open the possibility of changing data on stack
defenses continued
Defenses (continued)
  • Canaries
    • put a known value on the the stack just in front of the return address
    • if the canary changes, assume a stack overflow occurred
defenses continued1
Defenses (continued)
  • Address space randomization (ASR)
    • the compiler shuffles the order in which the arguments and return address are stored on the stack
    • makes it harder for the attacker to find and overwrite the return address
defenses continued2
Defenses (continued)
  • Code examination
    • code reviews
      • manually read through code for known security holes
      • a very large job
    • code scanner
      • automatically reads through code for known security holes
      • lots of false positives
    • combined approach
input validation
Input Validation
  • Never assume
  • Inputs
    • network-facing – listening sockets
    • user-facing – GUI text boxes, command line inputs
    • parameters sent to system library functions
  • Attacker simply starts with large amounts of random data
  • Always validate inputs
format strings
Format Strings
  • C language printf()
  • Allows users to view the stack
  • Allows users to cause a buffer overflow
unsigned integer overflow
Unsigned Integer Overflow
  • Numbers are stored in a fixed number of bits
  • This limits the size of the number that can be stored
  • If two large (unsigned) numbers are added, the most significant bits are truncated and the number is wrong
unsigned integer underflow
Unsigned Integer Underflow
  • If a large (unsigned) number is subtracted from a small number , the result would be negative
  • If you are using unsigned (positive only) numbers, the result would be incorrectly interpreted
type conversion
Type Conversion
  • The C language has several variations on integer data types
  • A long int may occupy 32 bits
  • A short int may occupy 16 bits
  • The most significant part of a large integer stored in a long int would be truncated if copied to a short int
signed vs unsigned integers
Signed vs. Unsigned Integers
  • A signed integer could hold a negative number
  • If copied to an unsigned integer, the number would be incorrectly interpreted
  • Pointers are variables that hold addresses
  • Assigning an integer number to a pointer variable or performing arithmetic on a pointer can result in a bad memory access
  • If you are lucky, your program will stop with a memory access error
  • If you are not lucky, you may spend months looking for the problem
pointers continued
Pointers (continued)
  • If you are a bad guy, you can read or write parts of memory you should not have access to
sql injection attacks
SQL Injection Attacks
  • Structured Query Language (SQL) is the commonly used database manipulation language
  • The single quote mark (‘) is used to delimit strings
  • Sample input: Alice

select * from Users where name=‘Alice’

sql injection attacks continued
SQL Injection Attacks (continued)
  • Malicious input: carlo’ or ‘1’ = ‘1
  • Results in

select * from Users where name=‘carlo’ or ‘1’ = ‘1’

  • Since this statement is always true, login is permitted even if carlo is not a user
defense against injection
Defense Against Injection
  • Validate the inputs
  • Escape the characters with special meanings

select * from Users where name=‘carlo\’ or ‘\1\’ = ‘\1’

internal validation
Internal Validation
  • Every subroutine should check its inputs on every call
  • The success or failure of every subroutine should be checked when it returns a value
race conditions
Race Conditions
  • Time of check/Time of Use (TOCTOU) errors
  • Program checks a property of a resource, then assumes that property does not change in the time interval between the check and the use of the resource
  • Example:
    • User is authorized to access a file
    • User replaces the file with another between authorization and use
  • Malicious code - programs specifically designed to undermine the security of a system
    • Trojan horses
      • Login spoof
      • Root kits
    • Trap doors
    • Viruses and rabbits
      • Virus scanning
      • Macro viruses
    • Worms
      • The Morris worm
    • Logic bombs and Easter eggs
trojan horses
Trojan Horses
  • History – a hollow wooden horse used by the Greeks during the Trojan War
  • Today - a Trojan horse is a program that has two purposes: one obvious and benign, the other hidden and malicious
  • Examples:
    • Login spoof
    • Mailers, editors, file transfer utilities, etc.
    • Compilers
trojan horse example
Trojan Horse Example
  • Root kits
    • A root kit is collections of Trojan Horse programs that replace widely-used system utility programs:
      • ls and find (hides files)
      • ps and top (hides processes)
      • netstat (hides network connections)
    • Goal: conceal the intruder’s presence and activities from users and the system administrator
trap doors
Trap Doors
  • Trap doors are flaws that designers place in programs so that specific security checks are not performed under certain circumstances
  • Example: a programmer developing a computer-controlled door to a bank’s vault
    • After the programmer is done the bank will reset all of the access codes to the vault
    • However, the programmer may have left a special access code in his program that always opens the vault
  • A virus is a fragment of code created to spread copies of itself to other programs
  • Requires a host (typically a program):
    • In which to live
    • From which to spread to other hosts
  • A host that contains a virus is said to be infected
    • A virus typically infects a program by attaching a copy of itself to the program
  • Goal: spread and infect as many hosts as possible
viruses continued
Viruses (continued)
  • Virus may prepend its instructions to the program’s instructions
  • Every time the program runs the virus’ code is executed
    • Infection propagation – mechanism to spread infection to other hosts
    • Manipulation routine – (optional) mechanism to perform other actions:
      • Displaying a humorous message
      • Altering stored data or deleting files
      • Killing other running programs
      • Causing system crashes
  • Virus scanning programs check files for signatures of known viruses
    • Signature = some unique fragment of code from the virus that appears in every infected file
  • Problems:
    • Polymorphic viruses that change their appearance each time they infect a new file
      • No easily recognizable pattern common to all instances of the virus
    • New viruses (and modified old viruses) appear regularly
      • Database of viral signatures must be updated frequently
macro viruses
Macro Viruses
  • More than just programs can serve as hosts for viruses
  • Examples:spreadsheet and word processor programs
    • Usually include a macro feature that allows a user to specify a series of commands to be executed
    • Macros provide enough functionality for a hacker to write a macro virus:
      • Executed every time an infected document is opened
      • Has an infection propagation mechanism
      • May have a manipulation routine
    • Example: Microsoft Word:
      • AutoOpen macro – run automatically whenever the document containing it is opened
      • AutoClose macro – run automatically whenever the document containing it is closed
the melissa macro virus
The Melissa Macro Virus
  • Appeared in March, 1999
  • Exploited Microsoft Word macros
  • Spread by e-mail:
    • Victim received an e-mail message with the subject line “Important Message From NAME”
    • Infected Word document as an attachment:
    • When an infected document was opened:
      • Virus attempted to infect other documents
      • E-mail a copy of an infected document to up to fifty other people
        • E-mail addresses of the new victims were taken from a user’s Outlook address book
        • Value to use for NAME in the subject line was read from the Outlook settings
melissa continued
Melissa (continued)
  • In three days, infected more than 100,000 computers
  • Some sites received tens of thousands of e-mail messages in less than an hour
    • Mail server crashes
    • System performance degradation
  • Besides spreading the virus:
    • Modified the settings in Microsoft Word to conceal its presence
    • Occasionally modified the contents of the documents that it infected
    • Occasionally sent sensitive documents without the owner's knowledge
  • Virus = a program fragment
  • Worm = a stand-alone program that can replicate itself and spread
  • Worms can also contain manipulation routines to perform other actions:
    • Modifying or deleting files
    • Using system resources
    • Collecting information
the morris worm
The Morris Worm
  • Appeared in November, 1988
  • Created by a Computer Science graduate student
  • Brought down thousands of the ~60,000 computers then attached to the Internet
    • Academic, governmental, and corporate
    • Suns or VAXes running BSD UNIX
morris worm continued
Morris Worm (continued)
  • Used four different attack strategies to try to run a piece of code called the grappling hook on a target system
  • When run, the grappling hook:
    • Made a network connection back to the infected system from which it had originated
    • Transferred a copy of the worm code from the infected system to the target system
    • Started the worm running on the newly infected system
other malware
Other Malware
  • Logic bombs
    • dormant malicious code
    • triggered by something specific (date, action)
  • Easter egg
    • cute but harmless behavior
programming languages
Programming Languages
  • Memory safe languages
    • programs can only access intended memory
    • attackers cannot read/write arbitrary memory locations
    • cannot overflow buffers
  • not memory safe – C
  • memory safe – C# and Java
type safe languages
Type Safe Languages
  • Variables of a certain type can only be assigned values of that type
  • Enforced
  • Type safe languages are also memory safe
  • Programs run in a compartment (virtual machine) which has the minimum necessary privileges
  • Prevents information flow problems
  • Examples:
    • Java’s Virtual Machine (JVM)
    • .NET’s Common Language Runtime (CLR)
    • VMWare
  • Provide access protections on data
    • private
    • public
    • protected
  • Static analysis
  • Dynamic analysis
  • Use safer libraries
  • Type-safe C
secure development life cycle
Secure Development Life Cycle
  • Requirements – decide on features
    • minimize for complexity and security
    • maximize for marketability
  • Design - identify components and how they fit together
    • reuse existing components, quick to market
    • document and review design carefully
    • conduct threat modeling
    • focus on robustness
threat modeling
Threat Modeling
  • See how design stands up against attackers
  • Phase I
    • Look at entry points – list all ways adversary could provide input to system
    • Identify assets – what an attacker may want to have
    • Identify trust level for access to entry points and assets
    • Map entry points to assets and trust levels
threat modeling continued
Threat Modeling (continued)
  • Phase II
    • Define use cases
    • Define unlikely or ‘impossible’ use cases
    • List security-related design assumptions
    • Document third party components
    • Create data-flow diagrams for secure data
threat modeling continued1
Threat Modeling (continued)
  • Phase III
    • Construct the threat profile
    • Identify all possible threats to each entry point
    • Consider attack scenarios
    • Assign a threat classification (STRIDE)
    • spoofing, tampering, repudiation, information disclosure, denial of service or elevation of privilege
threat modeling continued2
Threat Modeling (continued)
  • Identify vulnerabilities (unmitigated threats)
  • Prioritize vulnerabilities
secure development life cycle1
Secure Development Life Cycle
  • Implementation
    • Time to market
    • Conduct code reviews
    • Focus on argument validation
    • Memory management
  • Testing
    • Test features a bit
    • Crash test, test to break
    • Perform security audits and pen testing
    • Unit testing
  • Common Security/Programming Mistakes
    • Buffer overflow
    • Integer overflow
    • Other malicious inputs
    • Race conditions
    • Malware
    • Insecure programming languages
    • Insecure software development life cycle
  • Smith and Marchesini, The Craft of System Security, Addison-Wesley, 2008.
  • Tjaden, Fundamentals of Secure Computer Systems, Franklin, Beedle & Associates, 2004.