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.998689264at_private> 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.998689464at_private> 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
This archive was generated by hypermail 2b30 : Sat Aug 25 2001 - 11:03:57 PDT