1 / 61

System Security Overview

System Security Overview. 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

tress
Télécharger la présentation

System Security Overview

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

  8. Limitations with chroot/jail

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

  10. Detecting Attacks

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

  12. Virus vs. Worm

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

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

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

  16. Misuse Detection

  17. An Example

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

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

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

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

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

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

  24. Confidentiality

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

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

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

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

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

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

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

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

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

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

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

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

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

  38. 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?

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

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

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

More Related