Vulnerabilities in apport and systemd-coredump allow for extracting system users' password hashes.

Qualys has discovered two vulnerabilities in the apport tools (CVE-2025-5054) and systemd-coredump (CVE-2025-4598), which are used to handle core files generated after process crashes. These vulnerabilities allow access to core files saved after the crash of suid applications or certain system background processes, which may contain cached user credentials or encryption keys in memory. The apport utility is automatically invoked to save core dumps in Ubuntu, while systemd-coredump is used in Red Hat Enterprise Linux 9+, Fedora, and many other Linux distributions.

An attack technique was demonstrated where conditions were created for the crash of the suid application unix_chkpwd and access to the core file with the state dump during the crash. The saved core dump contained hashes of system user passwords that remained in the memory of the crashed process after loading the contents of /etc/shadow. The possibility of exploiting the vulnerabilities has been demonstrated in Ubuntu 24.04 and Fedora 40/41, but it is assumed that other distributions are also susceptible to similar attacks.

Both vulnerabilities are caused by a race condition that allows the replacement of the crashed suid process with another process at the moment after the kernel begins handling the crash but before the user-space handler checks the process parameters via /proc/pid/files. The invocation of apport and systemd-coredump occurs as follows: the kernel, upon receiving information about the process crash, calls the handler specified in the file /proc/sys/kernel/core_pattern, and then passes the core dump content through an input stream.

The generation of the core dump and the invocation of the handler does not happen instantly, and this window of time is sufficient to replace the crashed suid process with a regular user process. In the case of replacement, the launched core dump handler will consider that the failure occurred not in the suid process, but in a regular user application, and will accordingly save the core file with access for the normal user, rather than just the administrator.

The attack on apport consists of the following steps:

  • A new process is spawned and the execve() function is called to launch a suid program, such as unix_chkpwd.
  • The time required for loading sensitive data into memory by the suid program is skipped (in the case of unix_chkpwd, loading the password hashes of all system users from the /etc/shadow file is expected).
  • Before the command execution ends, the process is sent the SIGSEGV or SIGSYS signal for emergency termination.
  • In response to the emergency termination, the kernel generates a core dump and starts the apport process to handle the core dump in user space.
  • After the apport is started, but before the analysis, the terminated process is sent a SIGKILL signal, and the process itself is replaced with another one without the suid flag. To bypass checks in apport, the new process is created within separate namespaces (user, pid, and mount namespace).
  • apport connects to the unix socket /run/apport.socket in the namespace created for the new process and sends a file descriptor for access to the core dump.

To obtain the required identifier for the new process that matches the identifier of the suid process, the suid process is stopped with the SIGSTOP signal before the SIGSEGV signal is sent, and during the pause, new processes are cyclically launched until a PID with a preceding number, close to the substitutable suid process, is obtained. After shifting the PID numbering, the suid process is sent the SIGSEGV and SIGCONT signals, after which SIGKILL is sent, and new processes are cyclically launched to achieve the same PID as that of the suid process.

As for systemd-coredump, on one hand, attacking it is easier because there is no need to replace the suid process with a process in a separate user space, and it is sufficient to achieve matching AT_UID and AT_EUID. On the other hand, systemd-coredump is written in C and launches quickly, which gives less time for substitution, unlike apport, which is written in Python and loads various pyc files during initialization. This issue is resolved by artificially slowing down systemd-coredump—when the suid file is called, a very large number of command-line arguments are passed, creating the necessary delay that occurs during the parsing of /proc/pid/cmdline.

During the vulnerability analysis, researchers also found that systemd-coredump does not specify the "%d" flag in /proc/sys/kernel/core_pattern when configuring the call, which allows an attacker to trigger a crash of background processes running with root privileges, spawning other processes while changing the user identifier to a non-privileged user under which the attack is carried out. This possibility enables an attack not only on setuid applications but also on processes such as sshd-session (OpenSSH), sd-pam (systemd), and cron, to extract sensitive data residing in their memory, such as private keys, password hashes from /etc/shadow, canary values from the stack, and data for bypassing Address Space Layout Randomization (ASLR).

You can track the publication of package updates in distributions on the following pages: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch. As a workaround to block vulnerabilities, it is suggested to disable core dump saving for suid programs and processes that drop privileges by setting the /proc/sys/fs/suid_dumpable parameter to 0. To completely resolve the issue, changes need to be made to the Linux kernel to implement the ability to pass information about a crashed process through the pidfd mechanism (pidfd is associated with specific processes and unlike pid, is not reassigned).

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster