Hello, with current CVS portable OpenSSH non-PAM password authentication fails with the system running in trusted mode. This does get an issue, because apparently current code does not use PAM for plain old passord authentication. The reason for failure is that password hashes are not being looked up using getspnam, but rather from /etc/passwd even in trusted mode, because DISABLE_SHADOW is being defined by configure for all versions of HP-UX. Michael
Created attachment 383 [details] Always check for iscomsec() on HP-UX Does this patch fix the trusted mode issue?
Attachment #383 [details] doesn't fix it, unless if (spw = getprpwnam(pw->pw_name) != NULL) is replaced by if ((spw = getprpwnam(pw->pw_name)) != NULL) or the "!= NULL" comparison is omitted. However, you might consider delegating pw hash retrieval to getspnam, as this library function will transparently select the correct source also when /etc/shadow shadowing (which has become available as addon product for 11i) is in use. getspnam is available on all versions since at least 10.20. You may then drop all HP-UX specific stuff from function shadow_pw. Function xcrypt will need to pick the correct hashing method (crypt vs. bigcrypt) based on the result of iscomsec(), just the way it does now. No change required on that part.
Created attachment 385 [details] Remove DISABLE_SHADOW for HP-UX 11.x, fix brackets. Not as tidy as I'd like, but does this fix it? Note: You will need to run "autoreconf" to rebuild configure, then re-run configure. Also: I just noticed that xcrypt.c has variable declarations after code within a block, which I think some compilers will choke on.
Created attachment 386 [details] Move protected pw hash retrieval to getspnam HP-UX trusted mode (as well as shadow mode on 11i, if installed and active) can be served by the very same code as Linux and Solaris are, at the top of function shadow_pw. Attached patch illustrates what I mean. It consists of removed lines only :) I tested it on 10.20, 11.00, and 11.11. The latter one with ShadowPassword installed and activated, and the same sshd binary as used on the 11.00 trusted system. It worked.
I understood what you were getting at, but am wary of breaking things I can't test. Will patch #386 break any currently-working configurations?
Hmm, how to guarantee this? But I would say, unless other platforms get accidentally recognized as HP-UX by configure, or define the __hpux macro, no platform but HP-UX can be affected by this change. On HP-UX 10.20, 11.00, and 11.11 I have tested it with both trusted and non-trusted mode, plus ShadowPassword on 11.11. The possibility remains that OS patch levels might affect it, but it's virtually impossible to test all possible configuration there... Furthermore, using getspnam for this purpose is in line with its specification, see getspent(3C). Without ShadowPassword installed it states getspent() is only supported on trusted systems. The secured password facility is implemented without the use of the /etc/shadow file. getspent(), getspnam(), setspent(), and endspent() read from the trusted system's protected password database (/tcb/files/auth/*/*) and not /etc/shadow. The file /etc/shadow is not used in any way by the HP-UX login facility. These routines return a null pointer and sets ERRNO to ENOENT if the system has not been converted to trusted system. In all other cases, the return value is set similarly to getprpwent(). See getprpwent(3) for more information. Programs using these routines must be compiled with -lsec. On 11.11 with ShadowPassword installed it says If libsec patch PHCO_27038 or later is not installed, then getspent(), getspnam(), setspent() and endspent() are supported only on trusted systems; getspnam_r() and fgetspent() are not supported. The secured password information is obtained from the Protected Password Database (/tcb/files/auth/*/*). If libsec patch PHCO_27038 or later is installed, then all of these functions are supported on standard systems, shadowed standard systems and trusted systems. The one exception to this is that getspnam_r() is not supported on trusted systems. On a standard system the secured password information is obtained from /etc/passwd. If the system has been converted to a trusted system, then the secured password information is obtained from the Protected Password Database (/tcb/files/auth/*/*). If the system has been converted to use shadow passwords, then the secured password information is obtained from /etc/shadow. See shadow(4). The patch referred to, PHCO_27038, however is part of the ShadowPassword software bundle, thus can be assumed to be present. Isn't this exactly the behaviour we want?
Anything that defines __hpux that isn't HP-UX deserves whatever it gets. This code was originally put there for a reason, I'm wondering if the reason is still valid now. My guess is that it was to support older trusted-mode boxes (does 10.10 do trusted mode?) or unpatched machines where getspnam doesn't work. Have asked stevesk.
Hi Darren, now that PAM is in distress (won't reason about why here) I think having pw hash retrieval directed to getspnam is even more desirable for all version of HP-UX. For 10.x versions still in use (10.20 presumably the vast majority) I have found OS patches containing the getwent family (not introducing it!) in libsec: 10.10 PHCO_11208 (published 1997/06/06) 10.20 PHCO_11214 (published 1997/06/09) both addressing "adding/removing users can cause getspwent(3) to loop". For 10.00 and 10.01 I had to unpack PHCO_9817 (published 1997/02/17) and examine libsec.1 using nm: _fgetspwent | 58032|extern|entry | _fgetspwent | 58128|extern|code |$CODE$ _fgetspwent_r | 73892|extern|entry | _fgetspwent_r | 73940|extern|code |$CODE$ _getspwaid | 57540|extern|entry | _getspwaid | 57612|extern|code |$CODE$ _getspwaid_r | 73016|extern|entry | _getspwaid_r | 73064|extern|code |$CODE$ _getspwent | 58528|extern|entry | _getspwent | 58576|extern|code |$CODE$ _getspwent_r | 74348|extern|entry | _getspwent_r | 74420|extern|code |$CODE$ _getspwnam | 56888|extern|entry | _getspwnam | 56936|extern|code |$CODE$ _getspwnam_r | 71548|extern|entry | _getspwnam_r | 71668|extern|code |$CODE$ _getspwuid | 57196|extern|entry | _getspwuid | 57268|extern|code |$CODE$ _getspwuid_r | 72312|extern|entry | _getspwuid_r | 72360|extern|code |$CODE$ fgetspwent | 58056|extern|entry | fgetspwent | 58128|extern|code |$CODE$ fgetspwent_r | 73916|extern|entry | fgetspwent_r | 73940|extern|code |$CODE$ getspent | 56576|extern|entry | getspent | 56648|extern|code |$CODE$ getspnam | 56752|extern|entry | getspnam | 56776|extern|code |$CODE$ getspwaid | 57564|extern|entry | getspwaid | 57612|extern|code |$CODE$ getspwaid_r | 73040|extern|entry | getspwaid_r | 73064|extern|code |$CODE$ getspwent | 58552|extern|entry | getspwent | 58576|extern|code |$CODE$ getspwent_r | 74372|extern|entry | getspwent_r | 74420|extern|code |$CODE$ getspwnam | 56912|extern|entry | getspwnam | 56936|extern|code |$CODE$ getspwnam_r | 71572|extern|entry | getspwnam_r | 71668|extern|code |$CODE$ getspwuid | 57220|extern|entry | getspwuid | 57268|extern|code |$CODE$ getspwuid_r | 72336|extern|entry | getspwuid_r | 72360|extern|code |$CODE$ So these functions are at least present. Can't test these very old ones, however, as we don't have any of them any more. All these patches are also the latest libsec patches for these platforms. My two cents are: Somebody running 10.x and not having patched OS for more than six years is likely to have more serious vulnerabilities to care for than OpenSSH. Cheers! Michael
what about: xcrypt() section where we have: # elif defined(__hpux) && !defined(HAVE_SECUREWARE) if (iscomsec()) crypted = bigcrypt(password, salt); else crypted = crypt(password, salt);
This remains fine in function xcrypt. Trusted systems, and only these, do use the bigcrypt hashing.
OK, I'm convinced. Patch id #386 applied to both HEAD and 3.7 branch. BTW, I've discovered how to convert to and from Trusted Mode via command line (it's /usr/lbin/tsconvert if anyone wanted to know) so I can now regression test Trusted and non-Trusted on the same box automatically.
Mass change of RESOLVED bugs to CLOSED