CVE-2024-47191: Critical Flaw in OATH-Toolkit PAM Module Could Lead to Root Exploits

by do son · October 6, 2024

A serious vulnerability has been identified in the OATH-Toolkit’s PAM module, exposing systems to potential root-level exploits when handling one-time password (OTP) authentication. This issue, tracked as CVE-2024-47191, was discovered by Matthias Gerstner of the SUSE Security Team following an internal report from fellow SUSE engineer Fabian Vogt. The vulnerability affects systems utilizing the oath-toolkit for OTP-based second-factor authentication, making it a notable threat to systems leveraging this module.

The oath-toolkit is widely used for managing OTPs, often as a second factor in password authentication. The problem stems from a feature introduced in version 2.6.7 that allows the OTP state file (known as usersfile) to be stored in a user’s home directory. The vulnerability was identified in the way the PAM module performs file operations in these directories.

As described by Gerstner, “Fabian noticed that the PAM module performs unsafe file operations in users’ home directories. Since PAM stacks typically run as root, this can easily cause security issues.” The expansion logic of paths like ${HOME} or ${USER} was not properly secured, leading to a serious security lapse.

The root cause of CVE-2024-47191 lies in how the PAM module interacts with the usersfile during OTP authentication. When a user authenticates, the PAM module invokes the oath_authenticate_usersfile() function in the liboath library, which is responsible for managing access to this file. However, as Gerstner points out, “Privileges are not dropped, and the function is not aware of the special privileged PAM context.”

This flaw enables an unprivileged user to exploit file operations carried out by the PAM stack, which runs with root privileges. For example, by creating a symbolic link (symlink) in their home directory, a user can trick the system into overwriting critical files like /etc/shadow, effectively gaining root access.

Gerstner outlines how easily this exploit can be triggered:

“This will cause /etc/shadow to be overwritten and its ownership will be changed to the to-be-authenticated user. The to-be-authenticated user can obtain full root privileges. No race condition needs to be won and no pathnames have to be guessed.”

The exploitation scenario is direct and does not require complex conditions or timing, making it an urgent security threat.

The SUSE Security Team acted swiftly to address the vulnerability. In collaboration with the original upstream author, they developed a patch to fix the issue. However, this task was more complex than it initially appeared, as explained by Gerstner in the report:

“The PAM module cannot know for sure if the target usersfile is supposed to be owned by root or by the to-be-authenticated user, or even some unrelated user.”

One of the core problems identified was a broken locking mechanism. In its original form, the module’s lock file could be unlinked prematurely, resulting in potential race conditions. Moreover, storing the lockfile in the user’s home directory could clutter the directory or lead to a local denial of service.

To counter these problems, SUSE implemented several key measures:

The usersfile path is now safely traversed using system calls that prevent symlink attacks.
Privileges are dropped to the owner of the usersfile, mitigating the potential for privilege escalation.
The locking mechanism was overhauled to avoid cluttering the user’s home directory, now utilizing the usersfile itself for locking.

This comprehensive patch is currently in use for SUSE’s products, though a more portable upstream solution was also released in version 2.6.12 of the oath-toolkit.

Upstream developers of the oath-toolkit also released a fix, which is included in version 2.6.12. While their approach aims for greater cross-platform compatibility, it does not address all the use cases considered by the SUSE Security Team. However, both solutions resolve the core vulnerability, protecting systems from the devastating privilege escalation attack outlined in the original report.