cosc 4765 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Cosc 4765 PowerPoint Presentation
Download Presentation
Cosc 4765

Loading in 2 Seconds...

play fullscreen
1 / 30

Cosc 4765 - PowerPoint PPT Presentation

  • Uploaded on

Cosc 4765. Software Security. Software security design issues. First the challenge of software security: Change:

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

Cosc 4765

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
cosc 4765

Cosc 4765

Software Security

software security design issues
Software security design issues
  • First the challenge of software security:
  • Change:
    • the conditions under which we established security policy change but we are slow to adapt and consider the new consequences. Software changes either faster than we can keep up, or so slowly that we do not notice it happening.
  • Complacency:
    • creeping laziness, we stop worrying about the security.
      • This worked in the past, so it must still work.
  • Convenience:
    • security mechanisms are the opposite of convenience and they exact a discipline which some find hard to uphold.
some common sense software security
Some common sense software security
  • Damage control and restriction of privilege:
    • Errors and bugs are going to occur. The key to software security lies in limiting privilege to minimize damage from inevitable errors
  • Check memory limits and input values carefully
    • What are the consequences of that incorrect input?
  • Implicit dependencies
    • What the hidden dependencies? Are the libraries correct? Does something rely on an insecure source?
  • Spoofing
    • Can we authenticate and verify information?
    • In other words, can we fool the application or O/S in doing something it should not.
open source and closed source
Open Source and Closed Source
  • Security by obscurity may not work
    • Reverse engineering
      • Disassembler: machine code to assembly
      • Discomplier: machine code to high-level language
      • Code obfuscation: make the code difficult to understand, raise the bar a little
some basic obfuscation techniques
Some Basic Obfuscation Techniques
  • Add code that never executes, or that does nothing
    • E.g., make computations far more complex than they need be
  • Move code around
    • Spread related information as far apart as possible
      • E.g., Copy and rename the same function, or put multiple functions into a single function
  • Encode your data oddly
open source and closed source 2
Open Source and Closed Source (2)
  • Open-source software – potentially more secure
    • The many-eyeballs phenomenon
      • Given enough eyeballs, all bugs are shallow
        • Need incentives
        • Many people don’t know and don’t think much about security
      • Vulnerability detection in source code is hard
        • E.g., which function has buffer overflow problem
attacks against the path
Attacks against the path
  • Hidden dependency that causes problems.
    • Layer behind issues.
  • In both *nix and windows there is a path variable
    • This allows us to enter application names without knowing the where the program is located.
      • Very easy to create a Trojan Horse program and then have an novice Sys Admin execute that code, instead of the one they intended to run.
      • This is why root's PATH should never include '.' (current directory)
attacks against the path 2
Attacks against the path (2)
  • IFS attack against the Bourne shell.
    • The IFS variable determines the characters which are to be interpreted as whitespace. It stands for Internal Field Separators. Suppose we set this to include the forward slash character: (Bourne Shell or Bash)
  • IFS="/ \t\n";
  • export IFS PATH=".:$PATH";
  • export PATH
    • Now call any program which uses an absolute PATH from a Bourne shell (e.g. system(), or popen() system calls).
    • This is now interpreted like this system("/bin/mail root"); ---> system(" bin mail root");
      • which would attempt to execute a commands called bin in the current directory.
buffer overflow
Buffer Overflow
  • Buffer overflow vulnerabilities
    • Dominate remote network penetration
    • Common and easy to exploit
    • Ability to inject and execute attack code
  • Goal of attack:
    • Subvert privileged program, take control of program and host
    • Place code then execute it
buffer overflows 2
Buffer Overflows (2)
  • Buffer handling of input streams is an important problem.
    • If you don't get it right from the beginning, using a secure standard, it will come back to haunt you.
  • Remember that strings have to be terminated with '\0' -- the buffer needs to be one byte bigger than you think
example 1 buffer overflows
Example 1: Buffer Overflows
  • Avoid simply reading until end of line or object, always limit the amount of input to less than your buffer size.
  • Example:
    • buffer[16];
    • scanf("%s",&buffer); OR cin >> buffer;
  • Always check the limits:
    • scanf("%15s",&buffer);
  • If you don't know what input you are expecting, make sure you check its length and its type.
example 2 buffer overflows
Example 2: Buffer Overflows
  • strcpy() example:
  • int i = 0xffffffff; char[4] ca;
    • i = 0xffffffff, ca = ""
  • strycpy(ca,”0123A”);
    • i = 0xffff0041, ca='3210'
  • //strlen(source) = 5, sizeof(ca) = 4, problem!!!
unsafe lib functions
Unsafe lib functions
  • strcpy (char *dest, const char *src)
  • strcat (char *dest, const char *src)
  • gets (char *s)
  • scanf ( const char *format, … )
  • printf (conts char *format, … )
  • See Teso’s article on string format attacks
    • listed at the end of this lecture.
what can we do with an overflow
What can we do with an Overflow?
  • With the correct string, we can change the program execution.
    • Change the return address, so the program will go somewhere else.
    • Carefully crafted string can change the code to be executed.
      • say to launch a root shell.
the string
The string
  • a well formatted string that (usually) contains
    • A nop region
    • A shellcode region
    • Return address region
  • And is the source string that is used to overflow the buffer
how it works
How it works
  • Suppose our app contained this:

void func(char *str) {

char buf[128];

strcpy(buf, str); }

    • When the function starts it would look like:
    • What if *str is 136 bytes long? After strcpy:

Stack grows

downwards, but

buffers are written

upwards in


how it works 2
How it works (2)
  • So now the injected code is run from the buffer because the return address is change to point to the buffer
    • Only needs to be close on the return address, because of the nops also inserted.
      • shell code = "execve(“/bin/sh”)
    • When func() exits, the user will be given a shell.
      • Why? Because strcpy does no bounds checking!
shell code
Shell Code
  • The Shell code is machine code that opens a shell
  • Where to get it?
    • Google is a good start
    • Hacker sites are even better
      • The string is sometimes called the "egg".
    • Example: shellcode for fingerd 0.7.8
    • "\x31\xdb\x89\xd8\xb0\x17\xcd\x80" "\xeb\x16\x31\xdb\x31\xc9\xf7\xe1" "\x5b\xb0\x0b\x88\x53\x07\x52\x53" "\x89\xe1\xcd\x80\xb0\x01\xcd\x80" "\xe8\xe5\xff\xff\xff/bin/sh";
defenses brute force
Defenses: “Brute Force”
  • “C culture” favors performance over correctness
  • Don’t use strcpy or sprintf
  • Overflows can be subtle, auditing can’t find all vulnerabilities
  • Debugging techniques minimize, not eliminate, vulnerabilities
defenses non executable buffers
Defenses: Non-executable buffers
  • Make data segment non-executable
  • Cannot inject executable code
  • Unix & MS Windows use dynamic code for performance
  • Make stack segment non-executable
  • Effective against injection attacks
defenses array bounds checking
Defenses: Array bounds checking

Stops all buffer overflow vulnerabilities

  • Via compiler (gcc patch)
    • Misses some cases or slowdown of code
  • Purify
    • Expensive, code slower
  • Type-safe languages
    • Security sensitive code in Java
      • Can be defeated by with signed java applications
    • JVM written in C
  • Fuzz testing or Fuzzing
    • Inputs invalid, unexpected, or random data
      • Including things like file formats, network protocols, environment variables, keyboard and mouse events, returns on databases, shared memory, even interleaving threads.
    • In the old days, sometimes called a “monkey test”
        • Have a monkey bang on the keyboard and see what happens.
fuzzing 2
Fuzzing (2)
  • What can it find:
    • Crashes, race conditions, failures, locks ups
    • Assertion failures
    • Memory leaks
    • And of course, unexpected results.
  • From all this we can find vulnerabilities in the code.
    • But fuzzing doesn’t necessary tell you where the problem in the code is.
defenses integrity checking
Defenses: Integrity Checking
  • Don’t prevent corruption, detect before dereference
  • Advantages in performance, compatibility, implementation effort
  • 3 levels:
    • Stack introspection
    • Activation record integrity – StackGuard
    • Code pointer integrity – PointGuard
defense chroot
Defense: chroot
  • To protect the O/S from a comprised system process, they can be boxed in with chroot.
    • Take ftp as an example:
      • It then uses a private directory, normally called ftp.
        • There are no setuid programs in these directories.
      • It executes chroot on it's directory
        • At this point it has no longer has access to the rest of the filesystem, only it's sub-tree.
      • lastly, while ftp is started as a root process, the ftp process then changes to normally a ftp account
        • In other words: drop all system privileges.
      • Now it's boxed in. It can't access anything it not supposed to.
      • The worst case, that process is comprised, but the rest of the O/S is still protected.
        • Restore data from backups and patch program if possible.
chroot problems
chroot problems
  • Somewhat difficult to setup environment correctly
    • Confine program to directory
      • but this directory may not contain utilities that program needs to call
    • Copy utilities into restricted environment
      • However, copying too many files may give the attacker to escape the jail
    • Does not monitor network access (even in jail, you can access any other IP, you can sniff packets)
    • No fine grained access control
    • Everything inside jail can be accessed, everything outside can’t. All files have to be duplicated.
chroot problems 2
chroot problems (2)
  • Files needed for /bin/sh

/usr/ shared object libraries

/dev/zero clear memory used by shared objects

/usr/lib/ general C library

/usr/lib/ dynamic linking access library

/usr/lib/ Internationalization library

/usr/lib/ Internationalization library

Some others

  • Files needed for perl
    • 2610 files and 192 directories
getting started
Getting started
  • To read more and find out other fun things try:
  • "Smashing the Stack for Fun and Profit" Aleph One,
  • Exploiting Format String Vulnerabilities, Team TESO.
  • Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade, Crispin Cowan, et al.
  • Buffer Overflow Attacks and Their Countermeasures, Sandeep Grove,
other sites of interest
Other sites of interest
  • security focus
  •, a French site, but the exploits are mostly in English.
  • lots of different exploits.
  • astalavista group at
  • phrack at