Software Security - Set-UID Privileged Programs

Need for Privileged Programs

Password Dilemma
- Permissions of /etc/shadow file:

seed@seedvm:~$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1828 Jan 21 17:42 /etc/shadow # Owner can write

How would normal users change their password? (users have no access)
- Behind the scenes, it accesses a file using a file descriptor (fd)
To be fair and consistent with the first lecture, the SEED user is part of the sudo group, so it can access the file and edit it (this is not the general case)

Two-Tier Approach

Implementing fine-grained access control will make operating systems over complicated
OS relies on extension to enforce fine-grained access control
- Some authors refer to extension as exception, but either one works & means the same thing in this case
Privileged programs are such extensions

graph TD
    A[Programs] -->|Request| B[Fine-grained Access Control by Privileged Programs]
    A -->|Request| C[Generic Access Control by OS]
    B -->|Approved| C
    C -->|Access| D[Protected Resource]
    A -->|Denied| X[Access Blocked]

Type of Privileged Programs

Daemons (unix-like) or Services (Windows)

Computer program that runs in the background
Needs to run as root or other privileged users

`Set-UID` Programs

Widely used in UNIX systems
Program marked with a special bit

`Set-UID` Concept

Allows user to run a program with the program owner’s privileges
Allows users to run programs with temporary elevated privileges
Example: The passwd program

seed@seedvm:~$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 55544 Feb  6  2024 /usr/bin/passwd
#  ^ special bit                          ^ red background (can't see here)
#            ^ owned by root

Special bit
- Uppercase S: special permission bit set only
- Lowercase s: special permission bit and execute permission set

seed@seedvm:~$ touch setuid_test
seed@seedvm:~$ ls
Desktop  Documents  Downloads  fileexample.txt  Music  Pictures  Public  setuid_test  snap  src-arm  src-arm.zip  Templates  Videos
seed@seedvm:~$ ls -l set*
-rw-rw-r-- 1 seed seed 0 Jan 22 00:51 setuid_test
seed@seedvm:~$ chmod 4664 set*
seed@seedvm:~$ ls -l set*
-rwSrw-r-- 1 seed seed 0 Jan 22 00:51 setuid_test # red background
seed@seedvm:~$ chmod 4764 set*
seed@seedvm:~$ ls -l set*
-rwsrw-r-- 1 seed seed 0 Jan 22 00:51 setuid_test # red background

Every process has 2 user IDs
- Real UID (RUID): Identifies real owner of process
- Effective UID (EUID): Identifies privilege of a process
  - Access control is based on EUID
When a normal program is executed, RUID = EUID
- They both equal to the ID of the user who runs the program
When a Set-UID is executed, RUID =/= EUID
- RUID still equal to the user’s ID, but EUID equals to the program owner’s ID
- If the program is owned by root (EUID = 0), the program runs with root privilege

Turn a Program into Set-UID

Change the owner of a file to root:

seed@seedvm:~$ cp /bin/cat ./mycat
seed@seedvm:~$ sudo chown root mycat
seed@seedvm:~$ ls -l mycat
-rwxr-xr-x 1 root seed 26968 Jan 22 01:05 mycat
#                                         ^ green text

Before Enabling Set-UID bit:

seed@seedvm:~$ ./mycat /etc/shadow
./mycat: /etc/shadow: Permission denied

After Enabling the Set-UID bit:

seed@seedvm:~$ sudo chmod 4755 mycat
seed@seedvm:~$ ./mycat /etc/shadow
root:*:19977:0:99999:7:::
daemon:*:19977:0:99999:7:::
# ...

What is Linux safety bar when changing permissions after Set-UID?

How is Set-UID Secure?

Theoretically speaking, the Set-UID mechanism is secure
- Restrict behaviour - user can only do what is in the program
Unsafe to turn some programs to Set-UID
- Example: /bin/sh because it allows the user to execute other programs
There is a need to conduct a security risk analysis to understand the attack surface of a program

Attack Surfaces of Set-UID Programs

graph TD
    A[User Inputs] --> B[Set-UID Programs]
    C[System Inputs<br>that can be controlled by users] --> B
    D[Environment Variables] --> B
    B --> E[Non-privileged Process<br>Controlled by User]

Sum of all possible points, or attack vectors, where an attacker can try to insert data or extract data.
Rule of thumb: the smaller the attack surface is, the easier it is to protect.

Attacks vias User Inputs

Explicit Inputs

Program may ask user to provide input
If inputs are not sanitized, they might become vulnerable
Example:
- Buffer overflow attack: If input data are copied to a buffer, it may overflow the buffer and cause the program to run malicious code
- Early versions of chsh did not sanitize input and allowed attackers to add a line (entry) to the /etc/passwd file

Unsafe Approach

Set-UID program
This program (catall.c) is supposed to run the program /bin/cat and display the content of every file
Input: filename
Use system() function to execute the command

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
    char *cat = "/bin/cat";
 
    if (argc < 2) {
        printf("Please type a file name.\n");
        return 1;
    }
 
    char *command = malloc(strlen(cat) + strlen(argv[1]) + 2);
    sprintf(command, "%s %s", cat, argv[1]);
    system(command);
    return 0;
}

Example Usage:

$ gcc -o catall catall.c
$ sudo chown root catall
$ sudo chmod 4755 catall
$ ls -l catall
-rwsr-xr-x 1 root seed 7275 Feb 23 09:41 catall
$ catall /etc/shadow
root:$6$012BPZ.K$fbPkT6H6Db4/B8cLWb....
daemon:*:15749:0:99999:7:::
bin:*:15749:0:99999:7:::
sys:*:15749:0:99999:7:::
sync:*:15749:0:99999:7:::
games:*:15749:0:99999:7:::
$ catall "aa;/bin/sh"
/bin/cat: aa: No such file or directory
# ← Got the root shell!
# id
uid=1000(seed) gid=1000(seed) euid=0(root) groups=0(root), ...

Security Flaw: Mixing data and code (command) in the single input
The command is not directly executed by system()
system(command) executes the command by calling “/bin/sh -c command”
Shell is executed first, then the shell will take command as an input, parse it, and execute it
To types two commands in one line, use semicolon (;)
With the quotation marks (""), we force the shell to execute the commands.
Shell runs 2 commands: “aa;/bin/sh”
- “/bin/sh aa”: nothing
- “/bin/sh”: executed with root permissions via Set-UID, returning the root’s shell

Safe Approach with `execve()`

execve(v[0], v, 0)

v[0] = Command name
v = Input data (can be by user) Example:

int main(int argc, char *argv[])
{
    char *v[3];
    if(argc < 2) {
        printf("Please type a file name.\n");
        return 1;
    }
    v[0] = "/bin/cat"; v[1] = argv[1]; v[2] = 0;
    execve(v[0], v, 0);
    return 0;
}

Why is it safe?

Code (command name) and data are clearly separated; there is no way for the user data to become code.

Attacks via System Inputs

Programs can get inputs from the underlying system
System inputs are usually trusted
Security Flaw: If users can control these inputs, then it might not be safe
Attack Vector: Race condition attack

Attacks via Environment Variables

Programs behaviour can be influences by inputs that are not visible inside a program
Environment variables are part of the environment where the program runs
Environment variables can be set by a user before running a program

seed@seedvm:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin

#include <stdlib.h>
int main()
{
	system("cal");
}

PATH Environment Variable
- Used by shell programs to locate a command if the user does not provide the full path for the command
- system(): call /bin/sh first
- system("cal"):
  - /bin/sh uses the PATH variable to locate "cal"
  - Attacker can manipulate the PATH variable and control how the "cal" command is found
    - PATH = AttackerFolder + Previous_PATH
    - PATH = . : $PATH
  - Attacker can then define its own "cal" to be executed on its folder (.)
    - The attacker version of "cal" can be malware
- Security control:
  - Provide the abolute path, so that the shell will not look in the environment variables to find the function

Capability Leaking

In some cases, privileged programs downgrade themselves during execution
Example: the su program
- This is a privileged Set-UID program
- Allows one user to switch to another user (say user1 to user2)
- Program stats with EUID as root and RUID as user1
- After password verification, both EUID and RUID become user2’s (via privilege downgrading)
Such programs may lead to capability leaking
Programs may not clean up privileged capabilities before downgrading

Attacks via Capability Leaking Example

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
 
void main()
{
    int fd;
    char *v[2];
 
    /* Assume that /etc/zzz is an important system file, 
     * and it is owned by root with permission 0644.
     * Before running this program, you should create
     * the file /etc/zzz first. */
    fd = open("/etc/zzz", O_RDWR | O_APPEND);
    if (fd == -1) {
        printf("Cannot open /etc/zzz\n");
        exit(0);
    }
 
    // Print out the file descriptor value
    printf("fd is %d\n", fd);
 
    // Permanently disable the privilege by making the 
    // effective uid the same as the real uid
    setuid(getuid());
 
    // Execute /bin/sh
    v[0] = "/bin/sh"; v[1] = 0;
    execve(v[0], v, 0);
}

The /etc/zzz file is only writable by root
fd: File descriptor created
setuid(getuid());: The privilege is downgraded
v[0] = "/bin/sh"; v[1] = 0;: Invoke a shell program, so the behaviour restriction on the program is lifted The program forgets to close the file, so the file descriptor is still valid ⇒ Capability Leak.

Principle of Isolation

Principle: Don’t mix code and data.

If an input is meant to be used as data, then it should be strictly used as data
- system() fails to provide proper isolation while execve() does not
Attacks due to violation of this principle:
- system() code execution
- Cross Site Scripting
- SQL injection
- Buffer Overflow attacks

Principle of Least Privilege

A privileged program should be given the power which is required to perform it’s tasks
Disable the privileges (temporarily or permanently) when a privileged program doesn’t need those
In Linux, seteuid() and setuid() can be used to disable/discard privileges
Different OSes have different ways to do that

Summary

The need for privileged programs
How the Set-UID mechanism works
Security flaws in privileged Set-UID programs
Attack surface
How to improve the security of privileged programs

Connor's Notes

⬅️ Back to portfolio

Explorer

COSC 4P50: Week 3 Notes

Software Security - Set-UID Privileged Programs

Need for Privileged Programs

Two-Tier Approach

Type of Privileged Programs

Daemons (unix-like) or Services (Windows)

`Set-UID` Programs

`Set-UID` Concept

Turn a Program into Set-UID

How is Set-UID Secure?

Attack Surfaces of Set-UID Programs

Attacks vias User Inputs

Explicit Inputs

Unsafe Approach

Safe Approach with `execve()`

Why is it safe?

Attacks via System Inputs

Attacks via Environment Variables

Capability Leaking

Attacks via Capability Leaking Example

Principle of Isolation

Principle of Least Privilege

Summary

Graph View

Table of Contents

Connor's Notes

⬅️ Back to portfolio

Explorer

COSC 4P50: Week 3 Notes

Software Security - Set-UID Privileged Programs

Need for Privileged Programs

Two-Tier Approach

Type of Privileged Programs

Daemons (unix-like) or Services (Windows)

Set-UID Programs

Set-UID Concept

Turn a Program into Set-UID

How is Set-UID Secure?

Attack Surfaces of Set-UID Programs

Attacks vias User Inputs

Explicit Inputs

Unsafe Approach

Safe Approach with execve()

Why is it safe?

Attacks via System Inputs

Attacks via Environment Variables

Capability Leaking

Attacks via Capability Leaking Example

Principle of Isolation

Principle of Least Privilege

Summary

Graph View

Table of Contents

`Set-UID` Programs

`Set-UID` Concept

Safe Approach with `execve()`