On Thu, 1 May 2003, Thilo Schulz wrote:

> This is !!NOT!! a problem specific to openssh.
> When I saw this topic come up I tried the same with proftpd, which also can
> use pam to establish the user's authentication.

I've not investigated this specific issue, but yes, this behaviour may be
common to other daemons supporting PAM authentication. The problem,
however, is not in PAM itself: every daemon should run auth_pam_password()
even for non-existent or non-allowed usernames.

/* deny if no user. */
if (pw == NULL)
return 0;
if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES)
return 0;
if (*password == '\0' && options.permit_empty_passwd == 0)
return 0;

return auth_pam_password(authctxt, password);

As you can see, within OpenSSH < 3.6.1p2 there are a number of cases where
auth_pam_password() wouldn't even be called, -- and this is easily
detectable remotely. PAM delays just make this remote detection easier.

But this is not a PAM problem at all: i think every daemon should
review their code paths for user authentication, in order to reduce
specific timing leaks (complete resolution of these problems may be a lot
harder).

Fot those who don't know it yet, i suggest an interesting reading:
"Execution path timing analysis of UNIX daemons", by Sebastian Krahmer.

http://stealth.7350.org/epta.tgz

Cheers,

--
Marco Ivaldi
Chief Security Officer Data Security Division
@ Mediaservice.net Srl http://mediaservice.net/

[ reply ]