6974822 2001-08-25 13:16 -0400 /63 rader/ Charles Chear <presto@tpgn.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-25 20:10 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: presto@tpgn.net
Mottagare: Bugtraq (import) <18953>
Ärende: qpopper and pam.d
------------------------------------------------------------
From: Charles Chear <presto@tpgn.net>
To: <bugtraq@securityfocus.com>
Cc: <presto@tpgn.net>
Message-ID: <Pine.LNX.4.33.0108251312590.26311-100000@beef.tpgn.net>
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
(6974822) /Charles Chear <presto@tpgn.net>/(Ombruten)
6976149 2001-08-25 19:16 -0400 /89 rader/ Ron Bradburn <ron@dialtone.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-26 01:56 av Brevbäraren
Extern mottagare: Charles Chear <presto@tpgn.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18958>
Kommentar till text 6974822 av Charles Chear <presto@tpgn.net>
Ärende: Re: qpopper and pam.d
------------------------------------------------------------
From: Ron Bradburn <ron@dialtone.com>
To: Charles Chear <presto@tpgn.net>
Cc: bugtraq@securityfocus.com
Message-ID: <3B8831D2.71BBAD02@dialtone.com>
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
(6976149) /Ron Bradburn <ron@dialtone.com>/(Ombruten)