1. James Walden Northern Kentucky University
Privileged Programs
James Walden
Northern Kentucky University

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.
CSC 666: Secure Software Engineering

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.
CSC 666: Secure Software Engineering

5. 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

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.
CSC 666: Secure Software Engineering

7. CSC 666: Secure Software Engineering
Privilege Profiles
CSC 666: Secure Software Engineering

8. Privilege Management Functions
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.
Nonzero returns are failures.
CSC 666: Secure Software Engineering

9. 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(
Drop privileges permanently. Assign new_uid to RUID, EUID, and SUID.
restore_priv()
Copy privileged user ID from SUID to EUID.
From SetUID Demystified.
CSC 666: Secure Software Engineering

10. 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

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.
CSC 666: Secure Software Engineering

12. 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

13. 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.
CSC 666: Secure Software Engineering

14. 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.
Race conditions are always a reliability issue, but sometimes also a security flaw.
CSC 666: Secure Software Engineering

15. Java Servlet Hit Counter
// Example from BSS, pp
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!"); }
Calculates number of times web page has been accessed.
CSC 666: Secure Software Engineering

16. 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”
Cannot be fixed by expressing the two statements as one: p.println(++count + “ hits so far!”)
It requires multiple JVM byte code instructions to execute the statement.
CSC 666: Secure Software Engineering

17. 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

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.
CSC 666: Secure Software Engineering

19. 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!");
Java provides synchronized keyword for critical sections. Note limitation of critical section to only required code.
CSC 666: Secure Software Engineering

20. 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

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); }
Kernel performs access checks based on EUID/EGID, so setuid root program can always open() a file regardless of permissions.
Access() function checks based on real UID/GID.
Sounds useful in SETUID programs, but access() always insecure because of race condition.
Ignore advice to use in Stevens, p. 82.
CSC 666: Secure Software Engineering

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/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.
Developer’s Invalid Assumption: filename refers to the same object in both access() and open() calls.
CSC 666: Secure Software Engineering

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 ptmp files; renames ptmp to passwd
Doesn’t modify passwd in place to avoid problems with programs reading partially modified passwd file. UNIX move action is atomic.
CSC 666: Secure Software Engineering

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
Attack directory can be any directory attacker has write access to.
CSC 666: Secure Software Engineering

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
CSC 666: Secure Software Engineering

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
CSC 666: Secure Software Engineering

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
CSC 666: Secure Software Engineering

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

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
File descriptors are initially obtained using a system call with a pathname.
CSC 666: Secure Software Engineering

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.
CSC 666: Secure Software Engineering

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 of stat()
Problem: calls that only use pathnames.
link(), unlink(), symlink()
mkdir(), rmdir()
CSC 666: Secure Software Engineering

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.
Remember lstat() gives stat on symbolic link, whereas stat() will give stat on file that is linked to.
Code in BSS, pp
CSC 666: Secure Software Engineering

33. 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 )
EUID=program owner, UID=runner of program
Only two UID changes allowed for non-setuid root programs:
1. Swap EUID, UID
2. Set EUID to UID
CSC 666: Secure Software Engineering

34. 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

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.
Tmpcleaner vulnerabilities.
Never close and re-open a file, or use filename in any way.
CSC 666: Secure Software Engineering

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
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
John Viega and Gary McGraw, Building Secure Software, Addison- Wesley, 2002.
David Wheeler, Secure Programming for UNIX and Linux HOWTO, HOWTO/index.html, 2003.
CSC 666: Secure Software Engineering