System Security Overview

1. System Security Overview

2. Security is a Broad Area • Prevent attacks • Authentication and Access control • Remove software bugs • Signature generation and filtering • Protect secrete • Encryption (RSA, public-private key, ..) • Detect attacks • Intrusion detection • Information flow tracking • Diagnose attacks • Vulnerability analysis • Recovery from attacks • Sandboxing Only talk about a few system-related topics

3. Motivation for Sandbox • Often have to take applications from outside sources and execute them locally: • To trade stocks, you must download a JAVA applet • To share files you must run a P2P client • To view a file you must download and run the viewer • Even programs coming for reputable sources may have bugs or unintended side effects: • Systems are too diverse, developer cannot possibly know about all possible side effects • End result, a great deal of code we run today is deemed “unreliable”

4. Sandbox Goal

6. Limitations of Conventional OS protection • Not enough isolation • Programs can still see what other processes are running on machines • Can see the entire file system • All programs running on the system have the same level of access to the system call interface • No fine-grain isolation • Either programs are running on the system and have access to all facilities that other programs have, or they aren’t on the system at all • OS’s can’t protect themselves very well • Once you get root, you can install drivers, change configurations, etc…You only need to compromise 1 root process to do this.

7. UNIX chroot [ROOT] / bin etc usr var home chroot james mike bin etc usr var home tom jerry

8. UNIX chroot • chroot command • chroot changes root directory • Confines code to limited portion of file system • Example use • chdir /tmp/ghostview • chroot /tmp/ghostview • sutmpuser (or su nobody) • Caution • chroot changes root directory, but not current dir • If forget chdir, program can escape from changed root • If you forget to change UID (process is still root), process could escape

10. Limitations with chroot/jail

11. Other Sandboxing Approaches • Software Fault Isolation • Modify binaries to catch memory errors • Wrap/trap system calls • Check interaction between application and OS

16. Detecting Attacks

17. Background Check • Trojans: • Malicious programs disguised as legitimate ones • Need to be executed by the user Do not propagate • Viruses: • Sections of code copied into other executable code • Spread by infecting binaries passed between computers • Worms: • Self propagating • Complete programs, often quite complex • These are the worst and most dangerous kind!

18. Virus vs. Worm

19. Intrusions • Definition of an intrusion, some examples: • An outsider is able to gain access as a legitimate user • A legitimate user is able to gain more privileges • Information is leaked from a system • Resources on the system are used • A program on system is modified • Behavior of the system is modified • Basically any event where access controls are breached

20. Intrusion Detection • Misuse Detection (Signatures) • A sequence of actions that violates a security policy • Can only detect “known” attacks • E.g. user modifies password file • Difficult to encode all instances of misuse • Anomaly Detection • Some statistical argument about events which are abnormal • E.g. user gives wrong password more than 3 times • Can detect unknown attacks

21. Anomaly Detection • Learning or Data Mining Approaches • Gather a large amount of data • Train statistical modeling algorithm on data set • Bayesian Nets • Hidden Markov Models • Data Mining models • Others… • Use the information on live or recorded events to try and detect new attacks

23. Misuse Detection

24. An Example

25. Other Examples • Buffer overflow detection: • A setuid system does an exec call with certain arguments • A network packet has a lot of nop’s in it • Extremely long arguments to string functions • SYN flooding: • Many, frequent SYN packets with no ACK’s following • • Misuse triggers are usually very specific • IDS may miss variants of known attacks

26. Generation of Attack Signatures • Input signature generation • Vigilante [SOSP’05] • Bouncer [SOSP’07] • Many others…

29. NIDS Limitations • Limited visibility • Can’t interpret encrypted traffic • Can miss attacks if they don’t occur on the network • Has trouble if placed at the gateway into a network of heterogeneous hosts • Records a lot of traffic • Very difficult to be discriminating • Usually end up recording everything • Requires a fair amount of disk space and I/O bandwidth • May also require CPU time if there is a lot of traffic and analysis is done in real time

30. Host-based IDS • Tripwire: • Records MD5 checksums of critical files and binaries • Also checks file attributes, I.e. size, dates, permissions, etc… • Periodically verifies that the files have not been modified • Good for detecting root kits • Root kit: • After breaking in, attacker wishes to hide her presence • Root kit is a set of Trojan binaries (ls, ps, netstat, etc…) • Hides files, processes belonging to attacker • May also include sniffers to gather username/passwords

31. Host-based IDS Limitation • Need an IDS for every machine • HIDS is accessible to the attacker once she breaks in • Usually part of the OS or an application • Attacker can tamper with the IDS system • If logs are on the system, attacker can “cook” them • Always log IDS data on another, hopefully more secure system! • HIDS has view of one system • Difficult to share data across systems

32. Challenges with IDS • There exist over 100 Intrusion Detection Systems • Both open source and commercial • Can be network based or host based or combination • Main problem • Too many false positives • System administrators tend to ignore warnings after a while • Difficult to determine a good IDS policy • Other problems • Protecting the IDS itself against attack

33. Confidentiality

34. Sensitive Data is Everywhere • Passwords, Credit Card numbers, Medical Data, Military Data, Financial Data, Cryptographic keys,etc. • Handled by Databases, Web Browsers, Mail Systems, etc.

35. The Fate of all this Data? • How long is a copy in memory? • How many copies are there? • Where were they copied to? • How did they get there? Answer depends on many parts: Operating System, Libraries, Compiler, etc.

36. An Example • Enter a password into your yahoo mail login in Mozilla • Where does it go? • Kernel random number generator • Kernel tty buffer • Kernel socket buffer • XFree86 event queue • Mozilla strings on the heap

37. Data Can Live a Long Time • In Memory • Allocator and workload dependant • On Disk • Swap file, Core Dumps, Hibernation, VM suspend • On another machine • Network mounted storage, core dump shipping

38. Why is this a Problem • Threats: • Host or Application Compromise • Accidental Leakage (Core shipping, leak to lower privilege) • Direct Physical Attack • Increased risk of exposure • Increases impact of compromise

39. Minimizing Data lifetime is Hard • Systems works against programmer • Zero out the contents: • Compilers may optimize it away • Program may unexpected halt before zeroing • Buffers in other components are out of programmers’ control • Interaction with features (logging, command history, etc) • Pin the memory: • OS Hibernation • VM suspending, migration • Programmers make mistakes

40. TaintBochs Usage Model • Record a sensitive workload in Taintbochs (e.g. Enter a password into a browser) • TaintBochs tracks sensitive data through memory • Log records complete history • Analyze results

41. Track Sensitive Data at the Hardware Level • Associate a “Tainted” bit with each byte • Shadow Memory: A = B in normal memory Taint(A) = Taint(B) in shadow memory • Taint at I/O interfaces • Keyboard • NIC

42. Taint Propagation • Instrumented Instructions propagate taints • Arithmetic instructions • I/O instructions (in/out) • Copy instructions • Basic Policy: If an input is tainted, output is tainted Ex: add $C,$A,$B # c = a + b C is tainted if A or B is Tainted

43. Recording Taints as they Propagate • Keep Running Log of • Changes to memory • Changes to Shadow memory • Snapshot Registers as taints propagate • $EIP = instruction that caused tainting • $ESP = stack of offending instruction/function

44. Information Flow Tracking • Can be used for • Detecting confidential information leaking • Detecting malicious hijacking (see LIFT presentation)

45. Discussion • Information flow ( or taint analysis) can be implemented at • Source code level • Binary code level • Tradeoffs?

46. Detecting Past and Present Intrusions through Vulnerability-Specific Predicates Ashlesha Joshi, Samuel T. King, George W. Dunlap, Peter M. Chen (SOSP-2005)

47. vulnerability introduced vulnerability discovered patch released patch applied Motivation • Red time interval: window of vulnerability during which exploit is possible • Prompt patching makes this interval smaller, but cannot eliminate it • What to do in what’s left of window of vulnerability?

48. vulnerability introduced vulnerability discovered patch released patch applied IntroVirt • Use vulnerability-specific, perturbation-free predicates to detect the triggering of a vulnerability • For “past” time interval, combine predicates with VM replay • For “present” time interval, combine predicates with a response strategy

49. Vulnerabilities-Specific Predicates • Why vulnerabilities-specific? • char *str = some_string; • int len = strlen(str); • char buf[BUFSIZE]; • strcpy(buf, str); (len >= BUFSIZE)

50. Goals • Predicates must not perturb the target state • Predicates should be able to check applications and OS • Installing new predicates should not shut down the target software • Predicates should be easy to write • Predicates should execute with low overhead