su(1) segfaults when there's pam_exec.so in the "auth" stack with the option expose_authtok. To reproduce, use the following "auth" config in /etc/pam.d/system: auth sufficient pam_exec.so expose_authtok /usr/bin/false auth required pam_unix.so use_first_pass nullok When removing the 'use_first_pass' option from 'pam_unix.so', su asks for a password a second time (as expected), but still segfaults. When removing the 'expose_authtok' option from 'pam_exec.so', the segfault is gone. A lot of (probably irrelevant) context is here: https://forums.freebsd.org/threads/su-segfaults-when-adding-some-custom-pam_exec-to-the-auth-stack.85112/
from pam_exec(8) expose_authtok Write the authentication token to the program's standard input stream, followed by a NUL character. Ignored for pam_sm_setcred(). problem is that it is not ignored when code _pam_exec() is trying to retrieve the auth token when it is called from pam_sm_setcred pam_get_item will set item to null; PAM_AUTHTOK item is set to null when pam_authenticate finishes then a strlen is performed on null and it segfaults if (options->use_first_pass || strcmp(func, "pam_sm_setcred") == 0) { /* don't prompt, only expose existing token */ rc = pam_get_item(pamh, PAM_AUTHTOK, &item); authtok = item; } ...... authtok_size = strlen(authtok) + 1; // <= bombs here
This patch should fix it. https://reviews.freebsd.org/D35169
The branch main has been updated by khng: URL: https://cgit.FreeBSD.org/src/commit/?id=b75e0eed345d2ab047a6b1b00a9a7c3bf92e992c commit b75e0eed345d2ab047a6b1b00a9a7c3bf92e992c Author: Yan Ka Chiu <nyan@myuji.xyz> AuthorDate: 2022-05-22 16:33:02 +0000 Commit: Ka Ho Ng <khng@FreeBSD.org> CommitDate: 2022-05-22 16:36:48 +0000 pam_exec: fix segfault when authtok is null According to pam_exec(8), the `expose_authtok` option should be ignored when the service function is `pam_sm_setcred`. Currently `pam_exec` only prevent prompt for anth token when `expose_authtok` is set on `pam_sm_setcred`. This subsequently led to segfault when there isn't an existing auth token available. Bug reported on this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263893 After reading https://reviews.freebsd.org/rS349556 I am not sure if the default behaviour supposed to be simply not prompt for authentication token, or is it to ignore the option entirely as stated in the man page. This patch is therefore only adding an additional NULL check on the item `pam_get_item` provide, and exit with `PAM_SYSTEM_ERR` when such item is NULL. MFC after: 1 week Reviewed by: des, khng Differential Revision: https://reviews.freebsd.org/D35169
^Triage: Assign to committer resolving
Thanks for the commit! What would be necessary to create an EN to get this fix on releng/* after MFC? Background: xscreensaver dropped all support for external PAM helpers in 6.03 and kscreenlocker from KDE plasma also removed their own helper in 5.25. I have a workaround based on pam_exec ready (port is prepared and tested), but it won't work without this fix. So, consequently, some port updates would be blocked...