Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html This Mrdkaaa character claims to have exploited this, but does not say how. The issue is that if do_pam_account() fails, do_authloop() will call packet_disconnect() with loginmsg as the format string (classic printf(foo) instead of printf("%s", foo) bug). The stuff that do_authloop() appends to loginmsg is harmless (the user name is safe, since at this point we know the account exists). The question is, what does loginmsg contain before do_authloop()? Can loginmsg at this point contain the "Last login" text? That one's unsafe since it contains the result of a reverse DNS lookup. DES -- Dag-Erling Sm?rgrav - des at des.no
Dag-Erling Sm?rgrav <des at des.no> writes:> Can loginmsg at this point contain the "Last login" text? That one's > unsafe since it contains the result of a reverse DNS lookup.a quick check suggests it can't, and AFAICT the offending code runs in the unprivileged child, so I really can't see how he exploited it. Does anybody know what's going on? DES -- Dag-Erling Sm?rgrav - des at des.no
On Wed, 9 Jul 2008, Dag-Erling Sm?rgrav wrote:> Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html > > This Mrdkaaa character claims to have exploited this, but does not say > how.hmm, loginmsg starts empty and is filled from three sources: - The contents of a sshd_config:Banner file (if any) - Password expiry messages generated by sshd - Messages generated by PAM Of these three, the PAM messages are the only ones that could possibly be attacker-controlled (e.g. echoing back a deliberately corrupted username), but I don't know off the top of my head whether any PAM modules will actually do that. The actual bug happens in the path that handles a failed PAM account check, so it will have accrued these messages. The second difficulty in exploiting this in the wild is that that the packet_disconnect() call should only ever happen in the unprivileged slave process. Maybe the reporter disabled privsep for his/her demo? -d