Summary: | <sys-libs/pam-1.0.4 MINDAYS not respected by pam for password changing (CVE-2009-0579) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Robert Buchholz (RETIRED) <rbu> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | kanelxake, pam-bugs+disabled |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=487216 | ||
Whiteboard: | B4 [noglsa] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 261167 | ||
Bug Blocks: | 261512 |
Description
Robert Buchholz (RETIRED)
2009-03-03 20:59:26 UTC
sys-libs/pam-1.0.4 is in the tree. for reference, http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/NEWS?revision=1.84.2.5&view=markup&pathrev=Linux-PAM-1_0-branch Arches, please test and mark stable: =sys-libs/pam-1.0.4 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" I do not thing pam-1.0.4 builds with stable libtool-1.5.26 (at least, on two different sparc systems and amd64 it doesn't build for me, but pam-1.0.1 is OK (as was -1.0.3 while it was around)). For example, /bin/sh ../libtool --tag=CC --mode=compile sparc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -DDEFAULT_MODULE_PATH=\"/lib/security/\" -DLIBPAM_COMPILE -I./include -DPAM_VERSION=\"1.0.4\" -mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe -D__GLX_ALIGN64 -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wwrite-strings -Winline -Wshadow -c -o pam_account.lo pam_account.c Followed by a lot of trash: =================================== ../libtool: line 848: X--tag=CC: command not found ../libtool: line 881: libtool: ignoring unknown tag : command not found ../libtool: line 848: X--mode=compile: command not found ../libtool: line 1015: *** Warning: inferring the mode of operation is deprecated.: command not found ../libtool: line 1016: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../libtool: line 1159: Xsparc-unknown-linux-gnu-gcc: command not found ============================= This seems to me to be pretty much a show stopper. Bug #261167, Peter (loki_val) fixed it a few minutes ago. Sorry for having missed it before! Thanks, that fixes it. Now, I see a failure on two sparc systems: FAIL: tst-pam_mkargv The problem comes as follows: This test checks output: argvlen=185, argc=4, argv[0]=user, argv[1]==, argv[2]=XENDT\userα, argv[3]=user=XENDT\user1 Now, argc and the four argv[] values are correct, but the program wants argvlen=333. This test is invalid, because argvlen = (1 + sizeof(argv))*(sizeof(char) + sizeof(char*)) and this is 333 when sizeof(char*) == 8. But on sparc it is not 8; it is 4. So I think pal-1.0.4 is probably good, but this test is not. I double-checked all this with this little test: ================================ #include <stdio.h> int main (void) { char * s = "user = XENDT\\userα user=XENDT\\user1"; int l, c, p, t; l = strlen(s); c = sizeof(char); p = sizeof(char *); t = (l + 1) * (c + p); printf("s=%s, len=%d, csz=%d, ptsz=%d, total=%d\n",s,l,c,p,t); return 0; } ======================== Please advise. (I'm willing to keyword pam based on this, but I do not like that test.) ppc64 done I've added a patch to fix the test on 32-bit systems. Upstream bug was already opened, but I also submitted the patch upstream. This should do it. (In reply to comment #8) > I've added a patch to fix the test on 32-bit systems. Upstream bug was already > opened, but I also submitted the patch upstream. This should do it. > That got it, thanks. Sparc stable, all tests now pass, and it works on my systems. Stable for HPPA. alpha/arm/ia64/s390/sh/x86 stable amd64 stable ppc done m68k stable CVE-2009-0579 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0579): Linux-PAM before 1.0.4 does not enforce the minimum password age (MINDAYS) as specified in /etc/shadow, which allows local users to bypass intended security policy and change their passwords sooner than specified. Ready to vote, I vote no. NO too, closing. |