bugtraq - Re: OpenSSH/PAM timing attack allows remote users identification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.30L2.0305021256510.31415-100000@dns.mediaservice.net>
Date: Fri, 2 May 2003 13:20:31 +0200 (CEST)
From: Marco Ivaldi <raptor@...iaservice.net>
To: Thilo Schulz <arny@....s.bawue.de>
Subject: Re: OpenSSH/PAM timing attack allows remote users identification

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/