The Penguin Boss is in a Fuss
- Javier Conejo del Cerro
- 4 jun
- 2 Min. de lectura
Two newly disclosed vulnerabilities in Linux crash handlers—CVE-2025-5054 and CVE-2025-4598—expose a subtle but severe risk. A local attacker with low privileges can leverage a race condition in tools like Apport and systemd-coredump to trick them into forwarding the privileged memory of crashed processes. The target? Password hashes from /etc/shadow and other sensitive information handled by SUID binaries.
These vulnerabilities affect Ubuntu, Red Hat Enterprise Linux (RHEL), and Fedora—three of the most widely used distributions in enterprise, cloud, and academic environments. With proof-of-concept (PoC) code already developed, the exploitation path is no longer theoretical. What starts as a local crash ends in credential theft—and potentially full system compromise.
Admins in the Crosshairs
The primary victims of this attack surface are system administrators and organizations operating in multi-user Linux environments. This includes:
Corporate servers and DevOps infrastructure,
Academic computing clusters,
Public and private cloud instances,
Any deployment where SUID binaries are still in use.
The attacker doesn’t need elevated privileges to start—the flaws allow unprivileged local users to extract root-owned memory, including password hashes and process-level secrets. In shared systems where multiple users log in, a single compromised account could lead to lateral movement, privilege escalation, and widespread internal access.
From Crash to Credential Theft
The breach begins when an attacker deliberately crashes a SUID binary, such as unix_chkpwd (used to verify passwords). Right after the crash, they quickly spawn a non-privileged process using the same PID inside a custom namespace. Due to race conditions in crash handlers, Apport or systemd-coredump misattribute the privileged crash to the attacker’s fake process and forward the entire core dump into their controlled namespace.
The result? The attacker gains access to sensitive process memory from the original root-level binary—including password hashes from /etc/shadow, encryption keys, and potentially credentials cached in memory. With these hashes in hand, offline cracking tools could yield cleartext credentials, exposing critical services and accounts.
While exploitation is complex—it requires precise timing and local access—the risk is real, and the impact, once successful, is critical.
Blocking the Leak Before It Starts
Until system updates are available, mitigation is essential. Red Hat and Canonical recommend:
Running echo 0 > /proc/sys/fs/suid_dumpable to block core dumps from SUID programs.
Patching Apport and systemd-coredump once fixed versions are released.
Monitoring logs for unusual crash activity or core dump usage.
Restricting local user privileges and hardening namespace handling.
Disabling unnecessary SUID binaries where feasible.
While disabling SUID core dumps may hinder legitimate debugging, it’s a necessary trade-off to protect root-level secrets. For high-security environments, this should be enforced as a default setting.
This incident is a textbook example of how local vulnerabilities can undermine root isolation—especially in shared environments. Core dump handlers, while critical for debugging, can become a backdoor if not tightly secured. Attackers no longer need to exploit remote services—they just need a crash, a namespace, and a race to win.
Patch early, monitor smart, and assume that even your most trusted binaries can be turned against you.
Comments