openssh unix dev - Feb 2002 - [Bug 117] OpenSSH second-guesses PAM

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





------- Additional Comments From djm at mindrot.org  2002-02-15 10:10
-------
> OpenSSH traditionally would not even start PAM, and
> now starts it specifying 'NOUSER' as the login name.
We have always used NOUSER, the recent patch just makes it consistent between
protocols 1 and 2.
> The second is to prevent username guessing attacks - by 
> always calling PAM the system should always suffer the 
> same timeouts/delays no matter the existance of the 
> attempted login.
I don't think this is the case: the auth code attempts 
all authentications with the fake username anyway, so 
this should not be an issue unless the PAM modules 
themselves are broken.

We rely on getpwnam() working in lots of places, so changing 
this would be a fair amount of work.




------- 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=117





------- Additional Comments From Darren.Moffat at Sun.COM  2002-02-15 10:47
-------
There is nothing wrong with calling pam_set_item to set an item to NULL and in
fact there are modules on Solaris that do exactly that for PAM_AUTHTOK.

PAM on Solaris would not have syslogged the pam_set_item message that is 
described in bug 114

There is nothing wrong in having a syslog message for pam_set_item being
called with the item value as NULL, however since it is perfectly valid to do
so this should be a debug only syslog message and either the case being
reported had pam framework debugging enabled or there is a bug in the Linux PAM
framework library.

It is perfectly valid to pass NULL as the user into pam_start; pam_start
ultimately calls pam_set_item to setup the PAM_USER.  If the application does
that then it should use pam_get_item(pamh, PAM_USER, &user) to find out
which
user was authenticated if pam_authenticate returned PAM_SUCCESS.

I would rather that OpenSSH passed NULL to pam_start than passing NOUSER.  There
could potentially be modules on the stack that will prompt for a user name
if PAM_USER is empty - this is perfectly valid PAM according to the XSSO spec
(which Linux PAM does not comply with - it has extended and embraced in an
incompatible way in some areas).
Passing the string "NOUSER" takes a way a valid username out of the
namespace,
what if there really was a user called nouser (The user account for some 
subsystem called 'no' for example or someone called Neil Ouser) the
pam_authenticate call might actually succeed - this probably isn't what you
were
expecting to happen in this case.

PAM_USER == NULL means I the application don't know the user name, anything
else
is taken to mean you the application are trying to authenticate the named user.

I believe the correct fix is for OpenSSH to pass NULL to pam_start when it
doesn't know the username and pass the username when it does.



------- 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=117





------- Additional Comments From abartlet at samba.org  2002-02-15 11:13 -------
The problem is that OpenSSH knows the username perfectly well at this stage.  It
just refuses to pass it on to PAM!

This means that PAM cannot log the fact that an invalid login was attempted -
which is my primary issue here.  I am doing some work on a product that is
hoping to use PAM to log all authenticaion failures in a consistant manner
across all system deamons.  

I see know reason why PAM cannot be told the truth, allowing this kind of thing
without ugly hacks to OpenSSH itself (the current way this is done).  

auth_sia_password() doesn't take a 'struct passwd' argument, why
should PAM have
to?  (The bits of auth_pam_password() and auth_password() that deal with the
pw->uid feild should really be in a single function, elsewhere)



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