How Attackers Break Programs, and How To Write Programs More Securely Matt Bishop Department of Computer Science University of California at Davis Davis, CA 95616-8562 United States of America email: [email protected] www: http://seclab.cs.ucdavis.edu/~bishop phone: +1 (530) 752-8060 © 2002 by Matt Bishop This page deliberately left blank. That is, this page would have been blank except that we had to put the notice "this page deliberately left blank" on it. Otherwise, you might have seen the blank page and worried that someone left a page out of your booklets. So, we put a note on the blank page to assure you that no-one forgot to put something on this page; indeed, we intended for it to be blank. But we could not live up to our intentions, for the reason stated above, so we couldn't put a blank page in here. We had to put a page with some writing on it. So we couldn't put the notice "this page deliberately left blank" because it's not true and, if we couldn't tell when a page is blank, you'd doubt the veracity of everything we did. So we wrote this paragraph to ... oh, heck, forget it. Table of Contents sections slides Overview..................................... 1— 13 Attacking Programs ........................... 14—123 Overview .......................14 — 20 Users and Privilege ...............21 — 29 Environment ....................30 — 48 Buffer Overflow ..................49 — 70 Numeric Overflow ................71 — 76 Validation and Verification .........77 — 92 Race Conditions..................93—112 Denial of Service ............... 113—121 Environment .................. 122—123 Writing Better Programs ......................124—379 Overview ..................... 124—126 Design Principles ............... 127—137 Users and Privileges ............ 138—167 Environment .................. 168—201 Validation and Verification ....... 202—225 Race Conditions................ 226—266 Files and Subprocesses.......... 267—279 Error Handling ................. 280—286 System and Library Calls ........ 287—326 Miscellaneous Points ............ 327—336 Examples ..................... 337—371 Resources .................... 372—378 Conclusion ..........................379 papers 1. M. Bishop, “Robust Programming,” handout for ECS 153, Introduction to Computer Security, Department of Computer Science, University of California, Davis. 2. M. Bishop, source code to the program lsu 3. M. Bishop, source code for the function mpopen 4. M. Bishop, source code to the function trustfile This page deliberately left blank. How Attackers Attack Programs … SANS 2002 Annual Conference How Attackers Attack Programs, and How to Write More Secure Programs Matt Bishop SANS 2002 ©2002 by Matt Bishop. Slide #1 All rights reserved. Author Information Matt Bishop Department of Computer Science University of California at Davis Davis, CA 95616-8562 email: [email protected] www: http://seclab.cs.ucdavis.edu/~bishop phone: +1 (530) 752-8060 ©2002 by Matt Bishop. Slide #2 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Goals of This Talk • Show you how attackers look at programs for potential vulnerabilities • Show you how to write programs which are: – To be run by root (or some other user) – Are setuid or setgid to you (or root, or …) – Can't be tricked into doing what they are not intended to do ©2002 by Matt Bishop. Slide #3 All rights reserved. About This Talk • Principles, concepts broadly applicable – They apply to Windows NT/95/98/2000, MacOS X, and all other systems – This talk draws examples, applications from various flavors of both UNIX and Linux systems • Issues arise in multiple languages – Examples here are from C (with a bit of shell scripting) – Same rules apply to PERL, CGI programming on the web (especially CGI programming!), shell scripts, etc. ©2002 by Matt Bishop. Slide #4 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference More About This Talk • Examples are both current and historical – Sub-theme is that these problems are old and recurring and we need to start handling them – Historical ones are often cleaner examples than current ones because the systems were simpler • Focus on implementation, not design – Design principles critical to secure programming –A class in itself • So in the interests of time, we’ll just skim them ©2002 by Matt Bishop. Slide #5 All rights reserved. Brief Table of Contents Overview 1– 13 Attacking Programs 14– 20 Users and Privileges 21– 29 Environment Variables 30– 48 Buffer Overflows 49– 70 Numeric Overflow 71– 76 Verification and Validation 77– 92 Race Conditions 93–112 Denial of Service 113–121 Conclusion 122–123 ©2002 by Matt Bishop. Slide #6 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Brief Table of Contents (con’t) Writing Better Security Programs 124–126 Design Principles 127–137 Users and Privileges 138–167 Environment 168–201 Verification and Validation 202–225 Race Conditions 226–266 Files and Subprocesses 267–279 Error Handling 280–286 System and Library Calls 287–326 ©2002 by Matt Bishop. Slide #7 All rights reserved. Brief Table of Contents (con’t) Miscellaneous Points 327–336 Examples 337–371 Resources 372–378 Conclusion 379 ©2002 by Matt Bishop. Slide #8 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Overview Goal of this section – To define various terms, including what a vulnerability is • What is a privileged program? • How does a security policy affect this? ©2002 by Matt Bishop. Slide #9 All rights reserved. Key Concepts • privilege – Running with rights other than those obtained by logging in; or running as superuser • protection domain – All objects to which the process has access, and the type of access the process has ©2002 by Matt Bishop. Slide #10 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Interesting Programs • Change privilege – Setuid, setgid programs • Assume atomicity of some functions – Checking access permission and opening a file • Trust environment – Programs that assume they are loaded as compiled – Programs that trust input to be well-formed – Programs that assume caller has cleaned up signals, open files ©2002 by Matt Bishop. Slide #11 All rights reserved. Heart of the Problem All vulnerabilities are defined with respect to a security policy, which says: – What the program is allowed to do • Access a particular directory – What the program is not allowed to do • Access any other files – Takes into account constraints imposed by system administration, organization procedures, law, etc. ©2002 by Matt Bishop. Slide #12 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference End of Overview Key points: • Privilege is not only setuid or setgid – If root runs a regular program, the resulting process is executing with privileges – If someone else runs one of your programs, the resulting process is executing with privileges • An attack is an attempt to violate the security policy – If violation occurs, attack is successful – If no violation of policy, attack failed ©2002 by Matt Bishop. Slide #13 All rights reserved. Attacking Programs Goal of this section – To explain how attackers look for problems, and show how they exploit them • Where to look • What to look for –A simple list; references have several models – Explore each list member in detail ©2002 by Matt Bishop. Slide #14 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Where To Look • Network servers – Unknown users can access them • Local servers – They perform acts normal users cannot • Anything setuid or setgid – These have privileges • Shared resources – Privileged and unprivileged users both use these – This includes (local, remote) clients of servers ©2002 by Matt Bishop. Slide #15 All rights reserved. Network Servers • Accessible from throughout the network • Gives access to system – Attacker may not have access to account on target • Usually has privileges of some kind – root or daemon; may be only that of ordinary user • But you can usually get whatever you need from any of these • May make bogus assumptions – Weak authentication (identity from IP address) • May be poorly written ©2002 by Matt Bishop. Slide #16 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Local Servers • Accessible through system entry point – Usually socket, shared directory, shared files • Usually has privileges of some kind – root, daemon, or some other system user • May make bogus assumptions – Determine requester’s identity from ancillary information (file ownership, etc.) • Initial environment may be poorly configured • May be poorly written ©2002 by Matt Bishop. Slide #17 All rights reserved. Setuid, Setgid Programs • Execute with privileges other than that of user • Executes in user’s environment – User’s environment may be incorrectly configured • Usually has privileges of some kind – root, daemon, or some other system user • May make bogus assumptions – Determine requester’s identity from ancillary information (file ownership, etc.) • May be poorly written ©2002 by Matt Bishop. Slide #18 All rights reserved. How Attackers Attack Programs … SANS 2002 Annual Conference Clients • Connect to (local or remote) servers • May not check input thoroughly – Browsers may pass environment information via command strings – If client is remote, can attack remote system with no other information beyond the server’s existence • Need not be privileged – Client connects to privileged