Control: tags -1 - security Control: severity -1 normal Hi Anders,
On Mon, Oct 20, 2025 at 09:30:13PM +0200, Anders Heimer wrote: > Hi Salvatore, > > Thanks for the quick review. And thanks to you for coming back quickly on the assessment and double-checking things. Appreciated. > > On 10/20/25 17:16, Salvatore Bonaccorso wrote: > > 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? > > I drew parallels to the SUSE scenario for CVE-2025-6018 to quickly. Since at > only invokes pam_env in the auth stack, I agree that is not vulnerable to > CVE-2025-6018. Ack! > Please reclassify the report accordingly; remove the security tag and lower > the severity. Done so now. > > 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. > If you want, I can open a merge request removing the deprecated > functionality of reading a user specific environment file. I would like to leave this decision to the maintainer of the package, but I think it is sensible. So I would suggest you go ahead filling a merge request for review from Jose. Regards, Salvatore
