[22423] in bugtraq
Re: qpopper and pam.d
daemon@ATHENA.MIT.EDU (Ron Bradburn)
Sat Aug 25 19:55:37 2001
Message-ID: <3B8831D2.71BBAD02@dialtone.com>
Date: Sat, 25 Aug 2001 19:16:34 -0400
From: Ron Bradburn <ron@dialtone.com>
MIME-Version: 1.0
To: Charles Chear <presto@tpgn.net>
Cc: bugtraq@securityfocus.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
For those interested, the following patch makes the behaviour more 'expected':
---cut---
--- popper/pop_pass.c.orig Sat Aug 25 19:05:41 2001
+++ popper/pop_pass.c Sat Aug 25 19:06:58 2001
@@ -368,7 +368,7 @@
*/
static int gp_errcode = 0;
static char *GP_ERRSTRING =
- "[AUTH] PAM authentication failed for user \"%.100s\": %.128s (%d)";
+ "[AUTH] Password supplied for \"%.100s\" is incorrect.";
static int
PAM_qpopper_conv ( int num_msg,
---cut---
Charles Chear wrote:
> Hello,
> Take a look at the two sessions I have with Qpopper on a Redhat Linux 7.x box from
> an RPM package of version 4.0.1.
>
> Existing account:
>
> [root@bart /etc]# telnet 10.10.10.1 110
> Trying 10.10.10.1...
> Connected to 10.10.10.1.
> Escape character is '^]'.
> +OK ready <22975.998689264@target.host>
> user validuser
> +OK Password required for validuser.
> pass valid
> -ERR [AUTH] PAM authentication failed for user "validuser": Authentication
> failure (7)
> +OK Pop server at target.host signing off.
> Connection closed by foreign host.
>
> Non-existent account:
>
> [root@bart /etc]# telnet 10.10.10.1 110
> Trying 10.10.10.1...
> Connected to 10.10.10.1.
> Escape character is '^]'.
> +OK ready <22984.998689464@target.host>
> user fakeuser
> +OK Password required for fakeuser.
> pass fakeeeee
> -ERR [AUTH] Password supplied for "fakeuser" is incorrect.
> +OK Pop server at target.host signing off.
> Connection closed by foreign host.
>
> If you take a look carefully between the two sessions, both give different
> auth fail responses. Using this, you can brute force and verify an account
> exists or not. The problem, I'm assuming, is the intrusion of pam.d in the
> whole authentication process.I also tested this on an FreeBSD 4.3 box with
> qpopper 4.0.3. There, the same fail response was given whether or not the
> username really did exist. I've also tested an install of qpopper on
> Redhat straight from a tarball that compiled without PAM support. It
> responded securely and as it should.. with the same response whether or
> not the account really exists.
>
> In conclusion and from what I have seen so far, the problem lies within
> the PAM integration with qpopper and not qpopper itself. The simplest
> solution would be to compile qpopper without PAM support.
>
> Adios,
> Charles Chear
>
> The Poor Gurus' Network
> http://www.tpgn.net
--
Ron Bradburn - Network Operations Center Manager
Dialtone Internet - Extremely Fast Linux Web Servers
phone://954-581-0097x175 fax://954-581-7629
mailto:ron@dialtone.com http://www.dialtone.com
