[Bug 1269] PAM Callback returns garbage if user unknown or root with disabled login in ssh-config

[bugzilla-daemon at mindrot.org]

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

           Summary: PAM Callback returns garbage if user unknown or root
                    with disabled login in ssh-config
           Product: Portable OpenSSH
           Version: v4.5p1
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: PAM support
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: openbsd at priv.de


If the sshd gets no entry for the user trying to login with
getpwnamallow, or if it is not allowed to login, pam is still consulted
to authenticate. This is done for hiding if the user exists or not, to
hide if the password is right and to hide if he is only blocked in
config and the password was right (pam would not delay if the password
was right).

The call of pam requires a callback function via which the pam module
is able to tell something. Things like information and errors BUT also
to ask for further input. The callback function of sshd for the pam
module returns allways the hard coded value

  \b\n\r\177INCORRECT

in the case of using for further input as input from user, if is called
in the a case mentioned in first paragraph. This behaviour is
implemented to make sure that the timing on trying to login as the root
user is handle same if it allowed by "PermitRootLogin" or not. It is
NOT the code to make sure he can't login: This is done later (Search
for "Internal error: PAM auth succeeded when it should have failed").

The problem is, that this modification of the input of the callback
function is also is done if the user is not known by getpwnamallow.

In this case if any other information, beside of password, is requested
by the pam module it gets the garbage as answer. This could be
username, cryptocard answer or anything else. No matter if the prompt
is hidden or not. This blocks many possible programming scenarios
unnessesary.

Second, through this manipulation the sshd makes it in situations
discoverable which user exists or not. Also it is not a very good idear
to send garbage and special characters to an unknown pam module just if
the user do not exist... This is a real security impact!

Attack Szenario:
The PAM module may react allways comprehensible with this special
information. For example echoing the input the user gave in a error
message, or telling that there are special character in the input you
gave. If a module react like this, it is possible to discover which
users ssh can resolv and which not. This is a internal information of
ssh the attacker gets, not of pam.

Maybe there are further attacks for such cases... I am unable to
complete the list of problems, cause I have no overview over pam
modules  using the callback function.

Further problems:
If a pam module is doing something with the information provided from
the callback function, it is impossible to request data for users not
existing for ssh. Furhter it is also unknown what it is doing with the
special characters. Maybe it uses just "\b" as an identifier cause of
the leading "\b\n". Maybe an attacker sets some password or something
else in the system to use this default as an backdoor or something like
that. I think this situation is unsatisfying.

Solutions:
I am going to post two possible fixes by attaching them to this
bugzilla. I have not an overview over the OpenSSH portable code in
detail, so I think the exactly patch should be proofed by one of your
team, and maybe improved.

One is simply to pass through informations if the user is unknown, the
second only blocks infos if the input was hidden. But the second is
wrong in sight of inferface specification: A hidden input must not be a
password.

Assumedly this bug is caused by neglecting that this callback function
is not only used for password. So it think needs realy to be fixed.

I hope there will be a fix in near future using the pam interface
correctly.




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