Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 940778 (CVE-2024-47191) - <sys-auth/oath-toolkit-2.6.12: local root privilege escalation in PAM module
Summary: <sys-auth/oath-toolkit-2.6.12: local root privilege escalation in PAM module
Status: IN_PROGRESS
Alias: CVE-2024-47191
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Security
URL: https://www.nongnu.org/oath-toolkit/C...
Whiteboard: B1 [cleanup glsa]
Keywords:
Depends on: 940902
Blocks:
  Show dependency tree
 
Reported: 2024-10-05 06:52 UTC by Sam James
Modified: 2024-10-12 07:24 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-10-05 06:52:21 UTC
"""


OATH Toolkit provides two components liboath and pam_oath. Pam_oath is normally run as root and assumes that the usersfile path setting value points to a root-controlled and protected file containing the OATH secrets (cryptographic HMAC keys) for users.

The documentation suggests using a root-owned /etc/users.oath and to do chmod go-rw /etc/users.oath on it. The design assumes that file permissions are set up to prevent malicious read or writes to the credential file by unauthorized users. Whether file permissions are setup correctly or not is not checked by the code.

On every successful authentication, the file is rewritten to prevent OTP replay attacks. The rewriting logic works by acquiring a POSIX file lock on a newly created *.lock file (in the same directory), and then writing file content to a newly created *.new file (also in the same directory). File ownership of the new file is set to the same as the original file. The original usersfile is replaced atomically with the newly created file.

With the introduction of the ${HOME} indirection variable in the usersfile parameter the design assumptions no longer holds. The feature was added in version 2.6.7 released on 2021-05-01.

A typical setup when ${HOME} is used in a usersfile value such as usersfile=${HOME}/.config/oath.secrets is to allow users to manage their own credentials. The file is owned by the user who is responsible for adding the secret to it, and to set read/write permissions on the file appropriately.

The security problem is easy to exploit. To demonstrate the vulnerability with a vulnerable version and configuration, create a symbolic link $HOME/.config/oath.secrets.new that points to a privileged file such as /etc/shadow. After successful login as the user, pam_oath/liboath has followed the symbolic link and rewrote the target file with new updated OATH credentials and sets ownership of that file to the user. The user is now able to modify /etc/shadow.

We are not aware of any active exploits in the wild of this flaw.
"""
Comment 1 Larry the Git Cow gentoo-dev 2024-10-05 07:22:41 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34b83aa52932b8f711e603a03f39536557585e92

commit 34b83aa52932b8f711e603a03f39536557585e92
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2024-10-05 07:10:04 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2024-10-05 07:22:06 +0000

    sys-auth/oath-toolkit: add 2.6.12
    
    Bug: https://bugs.gentoo.org/940778
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-auth/oath-toolkit/Manifest                   |  1 +
 sys-auth/oath-toolkit/oath-toolkit-2.6.12.ebuild | 81 ++++++++++++++++++++++++
 2 files changed, 82 insertions(+)