openssh bugs - Dec 2009 - [Bug 1681] New: conversation function for passwd auth method assumes instead of fail

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

           Summary: conversation function for passwd auth method assumes
                    instead of fail
           Product: Portable OpenSSH
           Version: 5.3p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: PAM support
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: zdenek.kotala at sun.com


PAM documentation says
(http://docs.sun.com/app/docs/doc/816-4863/emrbk?l=en&a=view):

----
Developers should make no assumptions about how PAM is to communicate
with users. Rather, the application should exchange messages with the
user until the operation is complete. Applications should display the
message strings for the conversation function without interpretation or
modification. An individual message can contain multiple lines, control
characters, or extra blank spaces. Note that service modules are
responsible for localizing any strings sent to the conversation
function.
----

But sshpam_passwd_conv() "Assumes that echo-off prompts are for the
password" and pass password as a reply. It could lead that password is
exposed to a wrong consumer.

Correct solution is to set AUTHTOK before pam_autheticate is called in 
sshpam_auth_passwd() function.

Something like this:

pam_set_item(sshpam_handle, PAM_AUTHTOK, password);

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

--- Comment #1 from Zden?k Kotala <zdenek.kotala at sun.com> 2009-12-04
02:43:35 EST ---
I forgot to mentioned, that sshpam_passwd_conv() should return
PAM_CONV_ERR in case of PAM_PROMPT_ECHO_OFF message.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

Tomas Mraz <t8m at centrum.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t8m at centrum.cz

--- Comment #2 from Tomas Mraz <t8m at centrum.cz> 2009-12-04 02:46:28 EST
---
Setting PAM_AUTHTOK will not work with Linux-PAM as this item is not
accessible by applications.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

--- Comment #3 from Zden?k Kotala <zdenek.kotala at sun.com> 2009-12-04
02:56:19 EST ---
As documentation and draft of XSSO standard says you really cannot read
AUTHTOK in application but it is not a problem. Application (in this
case ssh) does not need to read it because it could lead to leak a
passwd in some cases, but the information is in the PAM session and PAM
module can access it.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

--- Comment #4 from Tomas Mraz <t8m at centrum.cz> 2009-12-04 03:27:12 EST
---
Maybe the standard says that however I am just saying what current and
all previous Linux-PAM versions did - they do not allow neither to get
nor set the PAM_AUTHTOK item from application.

Maybe the setting PAM_AUTHTOK item from application should be allowed
in the future Linux-PAM versions however I do not think openssh can
depend on having the PAM_AUTHTOK available to the application.

Also not supporting the current way how the openssh password
authentication is implemented with PAM means that current PAM setups
might not work anymore - PAM modules for example might require
try_first_pass option to consult the PAM_AUTHTOK item at all before
calling the conversation function.

In fact the "assume that echo-off prompts are for the authtok" worked
fine in most of the PAM configurations and in the remaining special
cases the sshd should have been configured to use keyboard-interactive
authentication instead of password authentication.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

--- Comment #5 from Zden?k Kotala <zdenek.kotala at sun.com> 2009-12-04
03:43:04 EST ---
(In reply to comment #4)
> Maybe the standard says that however I am just saying what current and
> all previous Linux-PAM versions did - they do not allow neither to get
> nor set the PAM_AUTHTOK item from application.
Also Linux-Pan documentation says
(http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/mwg-expected-by-module-item.html#mwg-pam_set_item):

---
PAM_AUTHTOK

    The authentication token (often a password). This token should be
ignored by all module functions besides pam_sm_authenticate(3) and
pam_sm_chauthtok(3). In the former function it is used to pass the most
recent authentication token from one stacked module to another. In the
latter function the token is used for another purpose. It contains the
currently active authentication token. 
---

It is also mentioned in documentation from 2002/05/09. It should work
on linux as well. If not PAM modules stack could works together.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

--- Comment #6 from Tomas Mraz <t8m at centrum.cz> 2009-12-04 04:12:45 EST
---
Where do you see in the Linux-PAM documentation that it is available to
applications? It just says it is available to modules to pass the token
between each other in the stack.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

--- Comment #7 from Zden?k Kotala <zdenek.kotala at sun.com> 2009-12-04
06:28:35 EST ---
I'm sorry I overlooked it. It mentioned that it works only between
modules. I checked also Linux PAM code and there is a wrong check. Fix
is easy but it will take longtime to spread Linux distribution. :(

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #8 from Damien Miller <djm at mindrot.org> 2010-04-23 11:59:29
EST ---
Yes, this is one of the (many) horrors of PAM. Unfortunately for the
reasons discussed we cannot ever really get rid of this (PAM_AUTHTOK is
Linux-only). On the other hand, it is quite well understood how PAM
must be configured to operate correctly with SSH password
authentication. 

If the thought of this assumption in password auth is too much for you,
you can disable PAM or use keyboard-interactive authentication which
makes no such assumptions.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1681

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #9 from Damien Miller <djm at mindrot.org> 2011-01-24 12:34:03
EST ---
Move resolved bugs to CLOSED after 5.7 release

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.