openssh bugs - Sep 2003 - [Bug 633] Password authentication fails in HP-UX trusted mode due to DISABLE_SHADOW

http://bugzilla.mindrot.org/show_bug.cgi?id=633

           Summary: Password authentication fails in HP-UX trusted mode due
                    to DISABLE_SHADOW
           Product: Portable OpenSSH
           Version: -current
          Platform: HPPA
        OS/Version: HP-UX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: michael_steffens at hp.com


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



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From dtucker at zip.com.au  2003-09-05 15:32 -------
Created an attachment (id=383)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=383&action=view)
Always check for iscomsec() on HP-UX

Does this patch fix the trusted mode issue?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |627
              nThis|                            |
             Status|NEW                         |ASSIGNED
           Keywords|                            |patch





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From michael_steffens at hp.com  2003-09-05 17:40
-------
Attachment #383 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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #383 is|0                           |1
           obsolete|                            |



------- Additional Comments From dtucker at zip.com.au  2003-09-05 19:49 -------
Created an attachment (id=385)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=385&action=view)
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From michael_steffens at hp.com  2003-09-06 00:22
-------
Created an attachment (id=386)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view)
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From dtucker at zip.com.au  2003-09-06 00:41 -------
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?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From michael_steffens at hp.com  2003-09-06 01:17
-------
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?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From dtucker at zip.com.au  2003-09-06 12:00 -------
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From michael_steffens at hp.com  2003-09-24 21:37
-------
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



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From mouring at eviladmin.org  2003-09-25 00:09
-------
what about:

xcrypt() section where we have:

# elif defined(__hpux) && !defined(HAVE_SECUREWARE)
        if (iscomsec())
                crypted = bigcrypt(password, salt);
        else
                crypted = crypt(password, salt);





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633





------- Additional Comments From michael_steffens at hp.com  2003-09-25 18:07
-------
This remains fine in function xcrypt. Trusted systems, and only these, do use
the
bigcrypt hashing.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=633

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From dtucker at zip.com.au  2003-09-25 20:25 -------
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.