Control: tags -1 + moreinfo Control: retitle -1 1118448 atd: uses pam_env user_readenv=1 in auth stack (should it be removed?)
On Mon, Oct 20, 2025 at 11:07:23AM +0200, Anders Heimer wrote: > Package: at > Version: 3.2.5-1 > Severity: important > Tags: security > > The at package's PAM configuration file (/etc/pam.d/atd) contains > user_readenv=1 which makes it vulnerable to CVE-2025-6018, a local > privilege escalation vulnerability. > > CVE-2025-6018 allows unprivileged local attackers to inject arbitrary > environment variables via ~/.pam_environment, which can be used to > spoof system variables like XDG_SEAT and XDG_VTNR. This allows > attackers to gain "allow_active" privileges normally reserved for > physically present users, enabling unauthorized access to Polkit > actions. > > The user_readenv feature has been deprecated by PAM upstream due to security > concerns: > https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784 > > This is similar to bug #761600. > > Fix: Remove user_readenv=1 from pam.conf > > I have prepared a fix in my fork at: > https://salsa.debian.org/AndersHeimer/at While it is possibly a good idea to remove the use of th pam_env user_read+env for atd, for CVE-2025-6018 it was important that SUSE had pam_env called before pam_systemd in the *session* stack. In atd pam_env is only used only in the auth stack and in particular used last. Can you elaborate where you see a similar issue than CVE-2025-6018 for atd? Maybe I'm missing something? In any case we know that the functionality of reading user specific environment file is deprecated since 1.5.0 version of pam, and so it might be a good idea to drop the user_readenv=1 accordingly. Regards, Salvatore
