privileged programs

36
Privileged Programs James Walden Northern Kentucky University

Upload: vea

Post on 13-Jan-2016

86 views

Category:

Documents


0 download

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 Presentation

TRANSCRIPT

Page 1: Privileged Programs

Privileged Programs

James Walden

Northern Kentucky University

Page 2: Privileged Programs

Topics

1. Privilege Escalation

2. SetUID

3. Race Conditions

Page 3: Privileged Programs

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.

Page 4: Privileged Programs

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.

Page 5: Privileged Programs

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.

Page 6: Privileged Programs

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.

Page 7: Privileged Programs

CSC 666: Secure Software Engineering

Privilege Profiles

Page 8: Privileged Programs

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.

Page 9: Privileged Programs

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.

Page 10: Privileged Programs

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.

Page 11: Privileged Programs

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.

Page 12: Privileged Programs

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.

Page 13: Privileged Programs

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.

Page 14: Privileged Programs

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.

Page 15: Privileged Programs

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!"); }}

Page 16: Privileged Programs

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”

Page 17: Privileged Programs

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.

Page 18: Privileged Programs

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.

Page 19: Privileged Programs

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!"); }}

Page 20: Privileged Programs

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?

Page 21: Privileged Programs

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);

}}

Page 22: Privileged Programs

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.

Page 23: Privileged Programs

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

Page 24: Privileged Programs

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

Page 25: Privileged Programs

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

Page 26: Privileged Programs

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

Page 27: Privileged Programs

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

Page 28: Privileged Programs

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.

Page 29: Privileged Programs

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

Page 30: Privileged Programs

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.

Page 31: Privileged Programs

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()

Page 32: Privileged Programs

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.

Page 33: Privileged Programs

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 )

Page 34: Privileged Programs

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

Page 35: Privileged Programs

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.

Page 36: Privileged Programs

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.