Skip to content

Setuid Programs

  • Setuid programs - grant privileges to users temporarily
  • world-writable file - file which everyone can write
  • OS strategies for fine grained access control:
    • implementing access control policies within OS
    • using extensions (privileged programs)
  • types of privileged programs
    • daemons: run in background as root or other privileged user
    • setuid programs: programs marked with special bit, run with program owner's privilege
  • Every process has two user IDs
    • Real UI (RUID) - real owner of process
    • Effective UID (EUID) - privilege of process, access control based on EUID
  • for any normal process RUID==EUID, for setuid programs EUID is owners ID

  • change program to setuid:

    1
2
    sudo chown <username> <filename>  # set owner
chmod 4755 <filename>             # make is setuid

  • Set-UID gives temporary escalated privileges

  • Different from directly giving the sudo-privilege to user

Possible Attacks

  • Attack surface of setuid programs
    • system inputs controllable by user
    • user inputs
    • environment variables
    • non-privileged process controlled by user
  • Attacks via user inputs due to failure to sanitize input
    • buffer overflow: overflow buffer to run malicious code
    • format strings: using user input as format strings causing change in program behavior
    • changing default shell
    • creating new root account
  • Attacks via system inputs, race conditions
    • symbolic link from unprivileged file to a privileged file
    • writing inside world-writable file
  • Attacks via environment variables
    • influencing program behavior through variables outside program
    • set by user before executing a program
    • e.g. changing path
  • Capability leaking can occur when privileged program downgrades during execution if program does not clean up capabilities before downgrading
    • e.g. su and file descriptor left open
  • Issues with invoking programs
    • invoking command inside setuid program
    • user should not be able to provide this command
    • can occur if input is not sanitized or command is invoked incorrectly
    • dangerous to invoke with C system() better to use execve()

Countermeasures

  • do not mix code and data → several attacks result from failure to do this:
    • system() code execution
    • cross-site scripting
    • SQL injection
    • buffer overflow attacks
  • principle of least privilege → provide only least necessary access

Writing a setuid program

(Summary of How to write a setuid program)

Process has two sets of ids: real and effective UID/GID

  • real: always user of process/the one executing file
  • effective: in setuid mode/when setuid bit of set → the owner of file
  • otherwise effective is same as real UID/GUID

Attacks on setuid programs

  1. executing commands defined by attacker

    • attacker takes advantage of setuid running with special privileges
    • ex. files scheduled with at-program will be run as file owner

  2. substituting data of attacker's choosing for data created by program

Env variables

Issues related to environment variables, e.g. uid, guid, opened files, path

  • these variables are inherited by subprocesses
    → Choose UID/GID that are as restrictive as possible
  • file descriptors stay open
    → Close all unnecessary file descriptors
  • exec maybe called within libraries/subprocesses
    → Reset effective UID before exec
  • linked directories can change access
    → check restricted root really restricts
  • modifying PATH or IFS can result in not executing intended program badly set umask may create world-writable file if interrupted at right time
    → check environment in which process runs

Programming style

Issues with programming style

  • applying setuid bit to command interpreter
    → do not write interpreted setuid scripts
  • using creat to create lock files since root can bypass its protection
    → do not use creat for locking, use link
  • dumping core can create world-writable file
    &arra; catch all signals
  • process data may not be valid, do not make assumptions about integrity
    → verification must verify
  • when errors occur, do not attempt to correct but stop, the cause of error maybe based on false assumption
    → make only safe assumptions about error recovery
  • if setuid process created file, it may not have permission and fail, or created as world-writable if interrupt happens after file creation but before changing owner
    → be careful with I/O operations