Bug 1269 (atomlee1)

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.