Solar Designer <solar () openwall com> writes: This link requires authentication. I guess you meant to post:

https://gitlab.com/oath-toolkit/oath-toolkit/-/commit/95ef255e6a401949ce3f67609bf8aac2029db418 Fixed, thank you! The writeup is available here:

https://www.nongnu.org/oath-toolkit/CVE-2024-47191.html I note a few things:

1. Neither the SUSE nor the upstream patches change the supplementary groups. SUSE patches fork() and then in the child setgid() and setuid(). Upstream doesn't fork(), but switches with setegid() and seteuid(), and then back. If the intent is solely to avoid the need for fchown(), then that's sufficient. Hopefully, along with SUSE's openat() and flags magic or with upstream's fopen(, "x"), nothing more is needed. However, if the intent is to avoid even trying to access files in user's directory with potentially excessive privileges, then supplementary groups should also be switched or dropped.

I'm sorry I didn't get around to bringing this maybe-issue up in the pre-disclosure thread on the distros list (which Johannes Segitz from SUSE kindly started on September 27). I feel it was not essential to discuss/address pre-disclosure, and is fine to discuss in public now. Thanks for review and mentioning this! I added some comments:

https://gitlab.com/oath-toolkit/oath-toolkit/-/issues/47

I noticed that that there are Linux-PAM helpers to drop privileges:

https://github.com/linux-pam/linux-pam/blob/master/libpam/pammodutilpriv.c#L52

I have found another implementation of this in yubico-pam:

https://github.com/Yubico/yubico-pam/blob/master/dropprivs.c 2. Switching task credentials from library code is tricky, given that the program could have threads that don't expect this. setid() and setgroups() libc calls would typically affect all threads. On Linux, it's possible to affect the current thread only, which e.g. we do in tcb[1] by using setfsid() and direct setgroups() syscall (the latter only in our recent git code at this time, previously we used the libc function). I assume Simon is aware of the Linux specific way, but deliberately chose not to do this in upstream oath-toolkit for portability to non-Linux.

[1] https://www.openwall.com/tcb/ and https://github.com/openwall/tcb Thanks for the pointer! Yes, even the mild use of POSIX APIs in liboath usersfile.c causes portability problems today, so I would like to avoid adding more and ideally even remove the current usersfile stuff since it doesn't belong in the core HOTP/TOTP library.

The thread concern is worrying though, but I'm hoping usage of this API is not that widespread in any threaded applications. 4. As Simon also noted: SUSE's alternative patch and advisory can be found via:

https://security.opensuse.org/2024/10/04/oath-toolkit-vulnerability.html

It rely on Linux kernel specific features and uses fork() which was determined to be contrary to the liboath design, which aims to be portable to macOS and BSD and beyond. I agree fork() from library code is tricky, but not so much because of portability concerns. Making fork() work on Windows from within a library is not that fun. Again, the program using the library may not expect it to ever have an extra child process. Sure the library should use waitpid() on this specific process, yet the program could receive unexpected SIGCHLD. The combination of the program's threads and our fork() could also have unexpected consequences.

In tcb, we chose to make usage of fork() a PAM module option, so that by enabling it the distro or sysadmin acknowledges that it's acceptable in the specific PAM configuration. Our usage of fork() is for a different reason, though: "Using this option one can be sure that after a call to pamend(3) there is no sensitive data left in the process' address space." I wonder if this property would also be relevant in oath-toolkit patches if more processing is moved to the child process, or if this would be excessive under the relevant threat models. Nice catch, I've opened an issue about this aspect:

https://gitlab.com/oath-toolkit/oath-toolkit/-/issues/48

Btw, do you have any thoughts on WHICH user to drop privileges to? The SUSE patch drops privs to the credential file owner. My patch drops privs to the PAM user that is being authenticated. I think there are reasonable arguments for both choices, and for all reasonable configurations that I'm aware of, I don't think the choice matters.

/Simon

The (1) configure and (2) config.guess scripts in GNU troff (aka groff) 1.20.1 on Openwall GNU//Linux (aka Owl) improperly create temporary files upon a failure of the mktemp function, which makes it easier for local users to overwrite arbitrary files via a symlink attack on a temporary file.

cryptblowfish before 1.1, as used in PHP before 5.3.7 on certain platforms, PostgreSQL before 8.4.9, and other products, does not properly handle 8-bit characters, which makes it easier for context-dependent attackers to determine a cleartext password by leveraging knowledge of a password hash.

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested source directory. A local attacker could use this flaw to mount an arbitrary directory, possibly leading to information disclosure.

Upstream fix: 764355487ea220fdc2faf128d577d7f679b91f97

References: https://bugs.launchpad.net/ecryptfs/+bug/732628

A number of flaws were reported [1] in eCryptfs that could allow a user to mount or unmount arbitrary locations, and possibly disclose confidential information:

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested mountpoint. A local attacker could use this flaw to mount to arbitrary locations, leading to privilege escalation. (CVE-2011-1831)

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested mountpoint. A local attacker could use this flaw to unmount to arbitrary locations, leading to a denial of service. (CVE-2011-1832)

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested source directory. A local attacker could use this flaw to mount an arbitrary directory, possibly leading to information disclosure. Note that this flaw also requires a fix in the kernel to be complete. (CVE-2011-1833)

Dan Rosenberg and Marc Deslauriers discovered that eCryptfs incorrectly handled modifications to the mtab file when an error occurs. A local attacker could use this flaw to corrupt the mtab file, and possibly unmount arbitrary locations, leading to a denial of service. (CVE-2011-1834)

Marc Deslauriers discovered that eCryptfs incorrectly handled keys when setting up an encrypted private directory. A local attacker could use this flaw to manipulate keys during creation of a new user. (CVE-2011-1835)

Marc Deslauriers discovered that eCryptfs incorrectly handled permissions during recovery. A local attacker could use this flaw to possibly access another user's data during the recovery process. (CVE-2011-1836)

Vasiliy Kulikov of Openwall discovered that eCryptfs incorrectly handled lock counters. A local attacker could use this flaw to possibly overwrite arbitrary files. (CVE-2011-1837)

[1] https://launchpad.net/bugs/732628

Multiple stack-based buffer overflow flaws were found in the way hardlink, the tool for consolidation of duplicate files via hardlinks, processed directory trees with deeply nested directories. A remote attacker could provide a specially-crafted directory tree, and trick the local user into consolidating it, leading to hardlink executable crash, or, potentially arbitrary code execution with the privileges of the user running the hardlink executable.

References: [1] http://www.openwall.com/lists/oss-security/2011/10/15/2 [2] https://bugs.gentoo.org/showbug.cgi?id=387269 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645516

Proposed patch (applied by the Owl Linux distribution): [4] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/hardlink/hardlink.c.diff?r1=1.1;r2=1.2

Sebastian Krahmer reported a command injection flaw in blkid. This could possibly result in command execution with root privileges (for example, when running blkid on a malicious USB drive):

http://www.openwall.com/lists/oss-security/2014/11/26/13

It was reported, that hardlink, the tool for consolidation of duplicate files via hardlinks operated on full file system objects path names. A local attacker could use this flaw to conduct symlink attacks (cause the hardlink executable to operate on directories / files outside of the intended directory tree).

References: [1] http://www.openwall.com/lists/oss-security/2011/10/15/2 [2] https://bugs.gentoo.org/showbug.cgi?id=387269 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645516

Proposed patch (applied by the Owl Linux distribution): [Adds section BUGS into the hardlink(1) man page documenting the danger] [4] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/hardlink/hardlink.1.diff?r1=1.1;r2=1.2

Multiple integer overflows, leading to heap-based buffer overflows were found in the way hardlink, the tool for consolidation of duplicate files via hardlinks performed string lengths concatenation in the calculation of the required memory space to be used. A remote attacker could provide a specially-crafted directory tree (with long directory and / or file names), and trick the local user into consolidating it, leading to hardlink executable crash, or, potentially arbitrary code execution with the privileges of the user running the hardlink executable.

References: [1] http://www.openwall.com/lists/oss-security/2011/10/15/2 [2] https://bugs.gentoo.org/showbug.cgi?id=387269 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645516

Proposed patch (applied by the Owl Linux distribution): [4] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/hardlink/hardlink.c.diff?r1=1.2;r2=1.3