Security ------------------- I. 2 Intro Examples II. Security Overview III. Server Security: Offense + Defense IV. Unix Security + POLP V. Example: OKWS VI. How to Build a Website I. Intro Examples -------------------- 1. Apache + OpenSSL 0.9.6a (CAN 2002-0656) - SSL = More security! unsigned int j; p=(unsigned char *)s->init_buf->data; j= *(p++); s->session->session_id_length=j; memcpy(s->session->session_id,p,j); - the result: an Apache worm 2. SparkNotes.com 2000: - New profile feature that displays "public" information about users but bug that made e-mail addresses "public" by default. - New program for getting that data: http://www.sparknotes.com/getprofile.cgi?id=1343 II. Security Overview ---------------------- What Is Security? - Protecting your system from attack. What's an attack? - Stealing data - Corrupting data - Controlling resources - DOS Why attack? - Money - Blackmail / extortion - Vendetta - intellectual curiosity - fame Security is a Big topic - Server security -- today's focus. There's some machine sitting on the Internet somewhere, with a certain interface exposed, and attackers want to circumvent it. - Why should you trust your software? - Client security - Clients are usually servers, so they have many of the same issues. - Slight simplification: people across the network cannot typically initiate connections. - Has a "fallible operator": - Spyware - Drive-by-Downloads - Client security turns out to be much harder -- GUI considerations, look inside the browser and the applications. - Systems community can more easily handle server security. - We think mainly of servers. III. Server Security: Offense and Defense ----------------------------------------- - Show picture of a Web site. Attacks | Defense ---------------------------------------------------------------------------- 1. Break into DB from net | 1. FW it off 2. Break into WS on telnet | 2. FW it off 3. Buffer overrun in Apache | 3. Patch apache / use better lang? 4. Buffer overrun in our code | 4. Use better lang / isolate it 5. SQL injection | 5. Better escaping / don't interpret code. 6. Data scraping. | 6. Use a sparse UID space. 7. PW sniffing | 7. ??? 8. Fetch /etc/passwd and crack | 8. Don't expose /etc/passwd PW | 9. Root escalation from apache | 9. No setuid programs available to Apache 10. XSS |10. Filter JS and input HTML code. 11. Keystroke recorded on sys- |11. Client security admin's desktop (planetlab) | 12. DDOS |12. ??? Summary: - That we want private data to be available to right people makes this problem hard in the first place. Internet servers are there for a reason. - Security != "just encrypt your data;" this in fact can sometimes make the problem worse. - Best to prevent break-ins from happening in the first place. - If they do happen, want to limit their damage (POLP). - Security policies are difficult to express / package up neatly. IV. Design According to POLP (in Unix) --------------------------------------- - Assume any piece of a system can be compromised, by either bad programming or malicious attack. - Try to limit the damage done by such a compromise (along the lines of the 4 attack goals). What's the goal on Unix? - Keep processes from communicating that don't have to: - limit FS, IPC, signals, ptrace - Strip away unneeded privilege - with respect to network, FS. - Strip away FS access. How on Unix? - setuid/setgid - system call interposition - chroot (away from setuid executables, /etc/passwd, /etc/ssh/..) How do you write chroot'ed programs? - What about shared libraries? - /etc/resolv.conf? - Can chroot'ed programs access the FS at all? What if they need to write to the FS or read from the FS? - Fd's are *capabilities*; can pass them to chroot'ed services, thereby opening new files on its behalf. - Unforgeable - can only get them from the kernel via open/socket, etc. Unix Shortcomings (round 1) - It's bad to run as root! - Yet, need root for: - chroot - setuid/setgid to a lower-privileged user - create a new user ID - Still no guarantee that we've cut off all channels - 200 syscalls! - Default is to give most/all privileges. - Can "break out" of chroot jails? - Can still exploit race conditions in the kernel to escalate privileges. Sidebar - setuid / setuid misunderstanding - root / root misunderstanding - effective vs. real vs. saved set-user-ID V. OKWS ------- - Taking these principles as far as possible. - C.f. Figure 1 From the paper.. - Discussion of which privileges are in which processes - Technical details: how to launch a new service - Within the launcher (running as root): // receive FDs from logger, pubd, demux fork (); chroot ("/var/okws/run"); chdir ("/coredumps/51001"); setgid (51001); setuid (51001); exec ("login", fds ... ); - Note no chroot -- why not? - Once launched, how does a service get new connections? - Note the goal - minimum tampering with each other in the case of a compromise. Shortcoming of Unix (2) - A lot of plumbing involved with this system. FDs flying everywhere. - Isolation still not fine enough. If a service gets taken over, can compromise all users of that service. VI. Reflections on Building Websites --------------------------------- - OKWS interesting "experiment" - Need for speed; also, good gzip support. - If you need compiled code, it's a good way to go. - RPC-like system a must for backend communication - Connection-pooling for free Biggest difficulties: - Finding good C++ programmers. - Compile times. - The DB is still always the problem. Hard to Find good Alternatives - Python / Perl - you might spend a lot of time writing C code / integrating with lower level languages. - Have to worry about DB pooling. - Java -- must viable, and is getting better. Scary you can't peer inside. - .Net / C#-based system might be the way to go. ======================================================================= Extra Material: Capabilities (From the Eros Paper in SOSP 1999) - "Unforgeable pair made up of an object ID and a set of authorized operations (an interface) on that object." - c.f. Dennis and van Horn. "Programming semantics for multiprogrammed computations," Communications of the ACM 9(3):143-154, Mar 1966. - Thus: - Examples: "Process X can write to file at inode Y" "Process P can read from file at inode Z" - Familiar example: Unix file descriptors - Why are they secure? - Capabilities are "unforgeable" - Processes can get them only through authorized interfaces - Capabilities are only given to processes authorized to hold them - How do you get them? - From the kernel (e.g., open) - From other applications (e.g., FD passing) - How do you use them? - read (fd), write(fd). - How do you revoke them once granted? - In Unix, you do not. - In some systems, a central authority ("reference monitor") can revoke. - How do you store them persistently? - Can have circular dependencies (unlike an FS). - What happens when the system starts up? - Revert to checkpointed state. - Often capability systems chose a single-level store. - Capability systems, a historical prospective: - KeyKOS, Eros, Cyotos (UP research) - Never saw any applications - IBM Systems (System 38, later AS/400, later 'i Series') - Commercially viable - Problems: - All bets are off when a capability is sent to the wrong place. - Firewall analogy?