1 / 36

Privileged Programs

James Walden Northern Kentucky University. Privileged Programs. Topics. Privilege Escalation SetUID Race Conditions. Privilege Escalation. Privileged programs : programs that have privileges to perform operations that the user running them would not otherwise have the right to do.

duff
Download Presentation

Privileged Programs

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. James Walden Northern Kentucky University Privileged Programs

  2. Topics • Privilege Escalation • SetUID • Race Conditions

  3. CSC 666: Secure Software Engineering Privilege Escalation • Privileged programs: programs that have privileges to perform operations that the user running them would not otherwise have the right to do. • Privilege escalation: Using a privileged program to obtain additional privileges beyond those the user ordinarily has. • Vertical: user gains uncontrolled access to the privileged program and is able to perform any action the privileged user could perform. • Horizontal: user uses program to gain access to other users’ data that he would not otherwise be able to see.

  4. CSC 666: Secure Software Engineering UNIX User IDs Real User ID (UID or RUID) • The owner of the process. Effective User ID (EUID) • The UID used by the operating system to make access control decisions. Saved User ID (SUID) • Stores previous UID so that it can be restored later. • Usually set to EUID when a SETUID program starts.

  5. CSC 666: Secure Software Engineering Propagation of User IDs fork() • All new processes created via fork(). • Child process inherits the 3 UIDs from parent. exec() • Loads a program image from a file. • Does not change UIDs unless • The program is SETUID, in which case • EUID and SUID are set to UID of file owner.

  6. CSC 666: Secure Software Engineering SetUID Programs • login: Uses SetUID privilege to change user IDs to those of user who successfully authenticates to login program. See also ssh, vmware-authd. • passwd: Uses SetUID privilege to modify /etc/shadow to change the user’s password. • crontab: Requires SetUID privilege to install and modify cron configuration files for users. • ping: Uses SetUID privilege to access raw network sockets and send broadcasts.

  7. CSC 666: Secure Software Engineering Privilege Profiles

  8. Privilege Management Functions CSC 666: Secure Software Engineering

  9. Chen, Wagner, Dean API CSC 666: Secure Software Engineering

  10. Linux Capabilities Divide monolithic root into capabilities. Examples: CSC 666: Secure Software Engineering

  11. CSC 666: Secure Software Engineering Linux Capabilities Files and processes have 3 capability sets: Inheritable: capabilities that will be inherited by child processes. Permitted: capabilities that the current process can obtain if it requests them. Effective: capabilities that will be applied to access control decisions for current process. Capabilities set when executing a program pI’ = pI pP’ = (X & fP) | (pI & fI) pE’ = fE ? pP’ : Ø where X is per-process capability bounding set.

  12. CSC 666: Secure Software Engineering Limit Filesystem Privilege Use chroot(path) to change system root. • Program sees path as /. • All files needed must be under path. • /etc/passwd: only contains necessary accounts • /lib/libc.so: and any other shared libraries. How to chroot() safely. • Close all open file descriptors. • Call chroot(), check errs, then chdir(). • Drop privileges.

  13. CSC 666: Secure Software Engineering Breaking out of a chroot() jail Re-chroot() with open filehandle above new root • Create temporary directory in CWD. • Open CWD, keeping an open fh above tmpdir. • Chroot(tmpdir) • Use fchdir() with CWD fh to move CWD outside the chrooted area. • Perform chdir(‘..’) to move CWD to /. • Chroot(‘.’), making root the real /. Direct disk access • Use mknod() to create a raw disk device. • Edit files directly using raw disk. Direct memory access • Use mknod() to create /dev/kmem. • Modify /dev/kmem to alter running OS kernel.

  14. CSC 666: Secure Software Engineering What is a Race Condition? • Incorrect behavior arising from unexpected dependency on relative timing of events. • Timing of events on multitasking system depends on system load. • Events generally happen in the expected order. • On multitasking system, processes can be interrupted between any two instructions. • Private resources (memory) are protected. • Shared resources (filesystem, network) can be modified by interrupting process.

  15. CSC 666: Secure Software Engineering Java Servlet Hit Counter // Example from BSS, pp. 210-211 public class Counter extends HttpServlet { int count = 0; public void doGet(HttpServletRequest in, HttpServletResponse out) throws ServletException, IOException { out.setContentType("text/plain"); Printwriter p = out.getWriter(); count++; p.println(count + " hits so far!"); } }

  16. CSC 666: Secure Software Engineering Analysis of Hit Counter • Assumes variable count does not change between incrementing and printing. • What if users A + B hit page at approximately the same time? • A is first, count = 1 • B is second, before println occurs, count = 2 • A sees “2 hits so far” • B sees “2 hits so far”

  17. CSC 666: Secure Software Engineering Window of Vulnerability • Period of time when violating assumption about order of events will produce incorrect behavior. • Generally <1s under ordinary conditions. • Small windows can be exploited. • Attackers can send multiple requests. • Attackers can slow the system down. • Local attackers may be able to suspend a process indefinitely with SIGSTOP. • Only secure window is one of zero size.

  18. CSC 666: Secure Software Engineering Critical Sections • Segment of code which may only be executed by one thread at a time. • Critical Section executes atomically from viewpoint of other threads. • Performance Impact • Other threads must wait for thread in critical section to finish executing. • Limit critical section size.

  19. CSC 666: Secure Software Engineering Synchronized Hit Counter // Example from BSS, p. 213 public class Counter extends HttpServlet { int count = 0; public void doGet(HttpServletRequest in, HttpServletResponse out) throws ServletException, IOException { int mycount; out.setContentType("text/plain"); Printwriter p = out.getWriter(); synchronized(this) { mycount = ++count; } p.println(mycount + " hits so far!"); } }

  20. CSC 666: Secure Software Engineering Time of Check, Time of Use TOCTOU Security Flaw • Perform access control check of resource. • Access resource. Problem • Has resource ACL changed between steps? • Has resource changed between steps, perhaps pointing to a different file or URL?

  21. CSC 666: Secure Software Engineering UNIX Example int main( int argc, char *argv[] ) { if(access( argv[1], W_OK ) == 0) { fd = open( argv[1], O_WRONLY ); writeFile(fd); } else { perror(“Permission denied.\n”); exit(1); } }

  22. CSC 666: Secure Software Engineering Analysis Window of Vulnerability • Time between access() and open() Exploit: rebind filename • Give filename as argument: /tmp/x • After access(), • delete /tmp/x • create link named /tmp/xpointing at root-owned file like /etc/passwd, /.rhosts Example: xterm log file race condition • Historically xterm was setuid to access utmp. • Could write log file to save xterm session.

  23. CSC 666: Secure Software Engineering ex: passwd [Bishop, 1996] passwd: allows user-specified passwd file Normal functioning • opens passwd file + reads user entry; closes • creates + opens temp file ptmp in same directory • opens passwd file again, then copies contents to ptmp with user changes • closes both passwd and ptmpfiles; renames ptmp to passwd

  24. CSC 666: Secure Software Engineering ex: passwd (cont.) Attacker Goal: rewrite /user/.rhosts • contents: localhost attacker ::::: • exploit: rlogin –l user localhost Plan of Attack • Create exploit .rhosts file in attack directory • Specify passwd file to be in attack directory • steps 1 + 3: directory containing passwd file is attack directory • steps 2 + 4: directory containing passwd:/user

  25. CSC 666: Secure Software Engineering passwd attack setup mkdir attackdir echo “localhost attacker :::::” > attackdir/.rhosts # want link to point to attackdir for step 1 ln –s attackdir link # specify password file using symlink dir passwd link/.rhosts

  26. CSC 666: Secure Software Engineering passwd: step by step passwd program opens + reads link/.rhosts actual file:attackdir/.rhosts Attacker changes link to point to /user passwd program creates + opens link/ptmp actual file: /user/ptmp Attacker changes link to point to attackdir

  27. CSC 666: Secure Software Engineering passwd: step by step passwd program opens link/.rhosts actual file: attackdir/.rhosts passwd program copies contents to ptmp actual file:/user/ptmp Attacker changes link to point to /user

  28. CSC 666: Secure Software Engineering passwd: step by step passwd program closes link/.rhosts + ptmp passwd program renames ptmptolink/.rhosts actual file:/user/.rhosts “Password” file is now target user’s .rhosts We can now rlogin to their account without needing a password.

  29. CSC 666: Secure Software Engineering UNIX File Binding UNIX provides two forms of naming pathname • universal mapping of names to objects • indirect: requires parent directories to identify file • mapping can be changed by another process file descriptor • per-process mapping of identifiers to objects • direct: file descriptor points directly to object • mapping cannot be changed by another process

  30. CSC 666: Secure Software Engineering TOCTOU Binding Flaws Occur with two sequential system calls: • insecure: Both call refer to same object by pathname. • insecure: One call uses file descriptor, other uses pathname. • secure: First call binds file descriptor to pathname, second uses that file descriptor. Solution: use calls that use file descriptors. Problem: some calls require pathnames.

  31. CSC 666: Secure Software Engineering TOCTOU Binding Flaws Solution: use calls that use file descriptors. • fchmod() instead of chmod() • fchown() instead of chown() • fstat()instead ofstat() Problem: calls that only use pathnames. • link(), unlink(), symlink() • mkdir(), rmdir()

  32. CSC 666: Secure Software Engineering Safe File Open • lstat()file before opening, saving stat structure. • open()file, obtaining file descriptor • use O_CREAT | O_EXCL flags. • specify permissions in open() call or use safe umask. • fstat() on file descriptor, saving stat structure. • Compare permissions (st_mode), inode (st_ino), and device (st_dev) of two stat structures. If identical, we know lstat() happened on same file we opened and that we did not follow a link.

  33. CSC 666: Secure Software Engineering Safe setuid File Operations • Using access() is always a race condition. • Change process EUID/EGID to the real UID/GID we want to use for check. • setreuid( EUID, UID ) • Perform file operations (access checks will apply to EUID/EGID). • Change back to privileged EUID/EGID when privileges needed again. • setreuid( UID, EUID )

  34. CSC 666: Secure Software Engineering When pathnames are necessary Keep files in their own, safe directory. • Set perms so only UID of program can access. Ensure parent directories are secure too. • mkdir safe directory • chdir safe directory • chdir .. + check permissions until reach root

  35. CSC 666: Secure Software Engineering Temporary Files C library • Filename generation functions: always a race. • tmpfile()insecure, varies between UNIXes. • mkstemp() is best choice, but • Creates files with mode 0666 on older systems. • Can lead to a dential of service if attacker precreates files. Solution: use private dir for temporary files. • Create directory securely. • Set permissions so only program can execute. • Use unlink() on files after creation to ensure cleanup even if program crashes.

  36. CSC 666: Secure Software Engineering References • Matt Bishop. “How Attackers Break Programs, and How to Write Programs More Securely”, SANS 2002, Baltimore, MD (May 2002). • M. Bishop and M. Dilger, "Checking for Race Conditions in UNIX File Accesses," Technical Report 95-9, Department of Computer Science, University of California at Davis (Sep. 1995). [PDF] [PS] • Hao Chen, David Wagner, and Drew Dean. “SetUID Demystified.” Proceedings of the USENIX Security Conference. 2002. • Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. • Mark Dowd, John McDonald, and Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007. • Serge Hallyn and ANdrew Morgan, “Linux Capabilities: making them work,” Proceedings of the Linux Symposium, July 23-26 2008. • John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. • David Wheeler, Secure Programming for UNIX and Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.

More Related