Bug 263893 - pam_exec.so in auth stack with expose_authtok option makes su segfault
Summary: pam_exec.so in auth stack with expose_authtok option makes su segfault
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Ka Ho Ng
URL: https://reviews.freebsd.org/D35169
Keywords: crash
Depends on:
Reported: 2022-05-10 10:43 UTC by Felix Palmen
Modified: 2022-05-28 08:55 UTC (History)
2 users (show)

See Also:
koobs: mfc-stable13?
koobs: mfc-stable12?


Note You need to log in before you can comment on or make changes to this bug.
Description Felix Palmen 2022-05-10 10:43:38 UTC
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/
Comment 1 titus m 2022-05-10 13:53:22 UTC
from pam_exec(8)
             Write the authentication token to the program's standard input
             stream, followed by a NUL character.  Ignored for

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
Comment 2 nyan 2022-05-10 18:31:11 UTC
This patch should fix it.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-25 00:53:52 UTC
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
    MFC after:      1 week
    Reviewed by:    des, khng
    Differential Revision:  https://reviews.freebsd.org/D35169
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-25 00:54:10 UTC
^Triage: Assign to committer resolving
Comment 5 Felix Palmen 2022-05-28 08:55:24 UTC
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...