Cosc 4765

1. Cosc 4765 Software Security

2. 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.

3. 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.

4. 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

5. 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

6. 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

7. 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)

8. 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.

9. 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

10. 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

11. 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.

12. 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!!!

13. 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.

14. 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.

15. 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

16. 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 memory

17. 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!

18. 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";

19. 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

20. 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

21. 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

22. Fuzzing • 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.

23. 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.

24. 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

25. 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.

26. 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.

27. chroot problems (2) • Files needed for /bin/sh /usr/ld.so.1 shared object libraries /dev/zero clear memory used by shared objects /usr/lib/libc.so.1 general C library /usr/lib/libdl.so.1 dynamic linking access library /usr/lib/libw.so.1 Internationalization library /usr/lib/libintl.so.1 Internationalization library Some others • Files needed for perl • 2610 files and 192 directories

28. Getting started • To read more and find out other fun things try: • "Smashing the Stack for Fun and Profit" Aleph One, http://www.shmoo.com/phrack/Phrack49/p49-14 • 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, http://www.linuxjournal.com/article/6701

29. Other sites of interest • security focus • http://www.k-otik.com/, a French site, but the exploits are mostly in English. • http://milw0rm.com/ lots of different exploits. • astalavista group at http://www.astalavista.com/ • phrack at http://www.phrack.org/

30. Q A &