Privileged Programs

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.