Software Security: Preventing Vulnerabilities in Coding - Prof. William Pugh, Assignments of Programming Languages

An overview of software security, focusing on the importance of preventing unintended software behavior and the risks of hidden trojans in compilers and operating systems. It also covers common security defects, such as buffer overflows and integer overflows, and the dangers of untrusted input. The document concludes with a discussion of format string vulnerabilities and sql injection.

Typology: Assignments

Pre 2010

Uploaded on 07/30/2009

koofers-user-hte
koofers-user-hte 🇺🇸

10 documents

1 / 38

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Software Security
CMSC 433
Bill Pugh
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26

Partial preview of the text

Download Software Security: Preventing Vulnerabilities in Coding - Prof. William Pugh and more Assignments Programming Languages in PDF only on Docsity!

Software Security

CMSC 433

Bill Pugh

Software Security

  • Making sure that if your software is misused, it doesn’t do any of the vast number of things you didn’t intend for the software to do

Compiler

  • Code generateCode(AST method) { if (method.getName() .equals(“authenticateLogin)) { return ... code with trap door ...; .. generate code normally

Slightly cool, but not very

interesting

  • Get spotted in a code audit

Trusted code base

  • Trusted code base is the code that, if compromised, causes all of your security to fail
  • Typically, includes all your software, your compiler, your operating system, ...
  • Feeling comfy?

Software defects

  • Traditional approach to correctness
    • define precondition
    • show that if precondition satisfied, output satisfied postcondition
  • Didn’t examine what happened if input didn’t satisfy precondition

Buffer overflows

  • In C, arrays are just locations in memory
  • if you write past the allocated end of the array, you write into something else
  • possibly other variables, return address
  • can both rewrite return address and deliver payload
  • http://insecure.org/stf/smashstack.html

Stack layout

int main(int argc, char *argv[]) { int value; char buf1[80]; … } argv argc return address frame pointer buf value

C String functions

char buf[20]; char * prefix = “http://”; strcpy(buf,prefix); strncat(buf, path, sizeof(buf));

C String functions

char buf[20]; char * prefix = “http://”; strcpy(buf,prefix); strncat(buf, path, sizeof(buf) - strlen(buf));

safe copy

#define MAX_BUF 256 void doStuff(char * in) { short len; char buf[MAX_BUF]; len = strlen(in); if (len > MAX_BUF) return; strcpy(buf, in); .. do stuff with buf ... }

Huh…?

  • C doesn't seem to give any warnings when invoking a function that returns an unsigned long long
  • and assign the result to something smaller - like a signed short or a char
  • Even with -Wall and -pendantic-errors

The little known %n

  • One of the least known and most dangerous format specified - %n expects the corresponding parameter to be the address of an int value - writes the number of characters written so far into that address
  • sprintf(buf, “%d%n”, x, &y)
    • stores into y the number of characters needed to represent x

Now we have a way

to update memory

  • Some hackers are very clever
  • Figured out how to turn several instances of this into an exploit - force a program to execute an arbitary payload