From ${URL} : The Linux-PAM project has released a new version to address a security issue in the pam_unix module. If the process executing pam_sm_authenticate or pam_sm_chauthtok method of pam_unix is not privileged enough to check the password, e.g. if selinux is enabled, the _unix_run_helper_binary function is called. When a long enough password is supplied (16 pages or more, i.e. 65536+ bytes on a system with 4K pages), this helper function hangs indefinitely, blocked in the write(2) call while writing to a blocking pipe that has a limited capacity. This bug may have security implications, e.g. allowing potential attackers to conduct username enumeration and denial of service attacks. We would like to thank Sebastien Macke of Trustwave SpiderLabs for the original bug report and Red Hat security response team for forwarding this issue. The code implementing pam_exec expose_authtok option and pam_unix_passwd.c had a similar issue but its security implications are not obvious. In the fix prepared by Tomas Mraz for this Linux-PAM release the verifiable password length is limited to PAM_MAX_RESP_SIZE bytes (i.e. 512 bytes). An alternative approach to fix this issue (implemented in such modules as pam_tcb) is to temporary ignore SIGPIPE and check for a failed/short write. This alternative was considered too complex for a security fix, though, and the simpler fix was chosen. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Commit message: Version bump http://sources.gentoo.org/sys-libs/pam/pam-1.2.1.ebuild?rev=1.1
pam-1.2.0 has been in the tree for over 30 days and i haven't seen any regression reports. 1.2.1 only fixes the security issues over 1.2.0, so that bump doesn't matter. it would be nice if 1.2.x could bake longer, but oh well. should be fine to stabilize 1.2.1 i think.
note: stabilize 1.2.1 and not 1.2.1-r1
amd64 stable
Stable for PPC64.
Stable on alpha.
Stable for HPPA.
x86 stable
ia64 stable
arm stable
ppc stable
sparc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Maintainer(s), Thank you for you for cleanup. New GLSA Request filed. Maintainer(s), please drop the vulnerable version(s).
It has been 30 days+ since cleanup requested. Maintainer(s), please drop the vulnerable version(s).
Can we please clean this up? We have all these versions available: pam-1.1.5.ebuild pam-1.1.6-r2.ebuild pam-1.1.8.ebuild pam-1.1.8-r1.ebuild pam-1.1.8-r2.ebuild pam-1.1.8-r3.ebuild pam-1.2.0.ebuild pam-1.2.1.ebuild pam-1.2.1-r1.ebuild
Cleanup complete: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0819b4caa858b34434c1d21217ffea94d76215b
This issue was resolved and addressed in GLSA 201605-05 at https://security.gentoo.org/glsa/201605-05 by GLSA coordinator Yury German (BlueKnight).
