privileged programs
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Privileged Programs
James Walden
Northern Kentucky University
Topics
1. Privilege Escalation
2. SetUID
3. Race Conditions
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.
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.
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.
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.
CSC 666: Secure Software Engineering
Privilege Profiles
CSC 666: Secure Software Engineering
Privilege Management Functions
Function Description
setuid(uid_t uid) Sets EUID of current process. If EUID of caller is root, sets RUID + SUID too.
seteuid(uid_t euid) Sets EUID of current process. Unprivileged processes may only set EUID to RUID, EUID, or SUID.
setreuid(uid_t ruid,
uid_t euid)
Sets RUID + EUID of current process. If RUID or EUID set to a value not equal to previous RUID, SUID set to new EUID.
setresuid(uid_t ruid,
uid_t euid,
uid_t suid)
Sets RUID, EUID, and SUID of current process. Supply -1 for each RUID or EUID leaves that ID unchanged. Unprivileged processes may set IDs only to current RUID, EUID, or SUID.
CSC 666: Secure Software Engineering
Chen, Wagner, Dean API
Function Description
drop_priv_temp(
uid_t new_uid)
Drop privileges temporarily. Move current privileged UID from EUID to SUID. Assign new_uid to EUID.
drop_priv_perm(
uid_t new_uid)
Drop privileges permanently. Assign new_uid to RUID, EUID, and SUID.
restore_priv() Copy privileged user ID from SUID to EUID.
CSC 666: Secure Software Engineering
Linux Capabilities
Divide monolithic root into capabilities. Examples:
Capability Description
CAP_CHOWN Change ownership, overriding DAC.
CAP_LINUX_IMMUTABLE Allow modification of S_IMMUTABLE and S_APPEND file attributes.
CAP_NET_BIND_SERVICE Allow binding to ports below 1024.
CAP_NET_BROADCAST Allow broadcast, listening to multicast.
CAP_NET_RAW Allow use of raw network sockets.
CAP_SYS_CHROOT Allow use of chroot().
CAP_SYS_PTRACE Allow ptrace() of any process.
CAP_SYS_BOOT Allow use of reboot().
CAP_SYS_NICE Allow raising and setting process priority.
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 programpI’ = pIpP’ = (X & fP) | (pI & fI)pE’ = fE ? pP’ : Ø
where X is per-process capability bounding set.
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.
CSC 666: Secure Software Engineering
Breaking out of a chroot() jailRe-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.
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.
CSC 666: Secure Software Engineering
Java Servlet Hit Counter// Example from BSS, pp. 210-211public 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!"); }}
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”
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.
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.
CSC 666: Secure Software Engineering
Synchronized Hit Counter// Example from BSS, p. 213public 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!"); }}
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?
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);
}}
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/x pointing 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.
CSC 666: Secure Software Engineering
ex: passwd [Bishop, 1996]
passwd: allows user-specified passwd file
Normal functioning1. opens passwd file + reads user entry; closes
2. creates + opens temp file ptmp in same directory
3. opens passwd file again, then copies contents to ptmp with user changes
4. closes both passwd and ptmp files; renames ptmp to passwd
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
CSC 666: Secure Software Engineering
passwd attack setupmkdir attackdirecho “localhost attacker :::::” > attackdir/.rhosts
# want link to point to attackdir for step 1ln –s attackdir link# specify password file using symlink dirpasswd link/.rhosts
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/ptmpactual file: /user/ptmp
Attacker changes link to point to attackdir
CSC 666: Secure Software Engineering
passwd: step by step
passwd program opens link/.rhostsactual file: attackdir/.rhosts
passwd program copies contents to ptmpactual file: /user/ptmp
Attacker changes link to point to /user
CSC 666: Secure Software Engineering
passwd: step by step
passwd program closes link/.rhosts + ptmp
passwd program renames ptmp to link/.rhostsactual file: /user/.rhosts
“Password” file is now target user’s .rhostsWe can now rlogin to their account without
needing a password.
CSC 666: Secure Software Engineering
UNIX File Binding
UNIX provides two forms of namingpathname
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
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.
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 of stat()
Problem: calls that only use pathnames. link(), unlink(), symlink() mkdir(), rmdir()
CSC 666: Secure Software Engineering
Safe File Open
1. lstat() file before opening, saving stat structure.
2. open() file, obtaining file descriptor
1. use O_CREAT | O_EXCL flags.
2. specify permissions in open() call or use safe umask.
3. fstat() on file descriptor, saving stat structure.
4. 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.
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 )
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
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.
CSC 666: Secure Software Engineering
References1. Matt Bishop. “How Attackers Break Programs, and How to Write
Programs More Securely”, SANS 2002, Baltimore, MD (May 2002).
2. 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]
3. Hao Chen, David Wagner, and Drew Dean. “SetUID Demystified.” Proceedings of the USENIX Security Conference. 2002.
4. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.
5. Mark Dowd, John McDonald, and Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007.
6. Serge Hallyn and ANdrew Morgan, “Linux Capabilities: making them work,” Proceedings of the Linux Symposium, July 23-26 2008.
7. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
8. David Wheeler, Secure Programming for UNIX and Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.