[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cobalt-developers] Popauth cont...

Portion of orginal message
=======================

Hello all,

While testing my new Raq3i, I discovered that my clients cannot
use CAPA (built-in password changing) in the Eudora mail client.

This is an important feature, because I don't grant UI access to
my users and I do require APOP.

I discovered that the version of qpopper 2.xx doesn't support this.
Also found that the version of qpopper 2.xx that comes with the 3i
according to quallcomm has some security holes in it. With suff. movtivation to attempt my first violation of the Cobalt warranty I did the following: 

1) cp /usr/sbin/in.qpopper /usr/sbin/old.in.qpopper
2) cp /usr/sbin/popauth /usr/sbin/old.popauth
3) ./configure --enable-specialauth --enable-bulletins=/var/spool/mail/bulletins --enable-log-login --enable-apop=/etc/pop.auth --with-popuid=admin 

4)  make
cd popper/
cp popper /usr/sbin/in.qpopper
cp popauth /usr/sbin/popauth

5) set owner/group ids and perms to match "old." files

6) tried accessing mail got "auth" error

7) tried reentering the passwds in UI and reenabling APOP

8) tried accessing mail again got "auth" error

9) mv /etc/pop.auth old.pop.auth

10) popauth -init

11) popauth -user jpape
pass:
pass:

12) tried accessing mail->success

13) attempted similar access for fictitious test client->no success

14) looks like qpopper 3.02 works fine, but popauth is not working
with the UI and I will have to build popauth entries from the command line
which defeats the whole purpose of enabling CAPA via qpopper 3.02 in the
first place.
15) As I have only replaced executables with executables of the same path,name, 
ownership and permissions, I can only assume that the problem lies with
my configuration specs for building qpopper and popauth or there is
some underlying mystery in cobalt UI.

16) In a worst case scenario, I assume that I can simply:
a) mv old.in.qpopper in.qpopper
b) mv old.popauth popauth
c) mv old.pop.auth pop.auth

and all will be well?

17) Any clues ASAP would be most appreciated.

JP


1st Reply
============================

Up to OS Update 2.0, the Raq3 UI had that problem with APOP accounts. Non of
my APOP accounts enabled via the UI did not work. Did it work before
upgrading to qpopper 3.0.2?

The main perl function that takes care of APOP accounts is the
"mail_apop_adduser" in the Email.pm file of the Cobalt perl libraries.

It is found in:
/usr/lib/perl5/site_perl/5.005/Cobalt/Email.pm

The function should look like this:

sub mail_apop_adduser
# adds a user to the APOP database
#   (can also be used to change password)
# arguments: user, password
# side effects touches APOP database
# return value: standard
{
    my ($user,$pw) = @_;
    my (%db,$obscurepw);
    $pw .= " ";

    foreach (unpack('C*', $pw)) {
        $obscurepw .= pack('C*', $_ ^= hex("ff"));
    }

    use GDBM_File;
    tie (%db, "GDBM_File", "/etc/pop.auth", GDBM_WRITER, 0600)
        or return(MSG_error("email_apop_cant_opendb"));

    $db{$user} = $obscurepw;
    untie %db;

    return(MSG_ok("email_apop_useradd_ok"));
}



The problem was that this function was not setting the password in the
pop.auth file correctly. popauth did set it right and everything worked
fine. I compared this function before and after the update, and the only
difference was the extra space added to the end of the password passed to
it:

$pw .= " ";

If it worked on your RAQ3 before you installed qpopper 3.0.2, maybe the
structure of the pop.auth file changed a little from the previous version.
Try removing the space and see if it works.

Regarding the security hole, yes it is there. I posted a message to this
list and the cobalt_security list about 3 weeks ago and no response yet.

JLA



1st response to 1st reply
=====================================

Tried commenting out the $pw .= ""; and found that qpopper 3.02 could not recog
the old unmodified pop.auth db entries. Initing the pop.auth file with the new
popauth (presumably called 3.02), reseting users via meta-verify, and reenabling a user as an APOP with a new passwd from the UI did not work--nor did I expect it to.
It appears that qpopper 3.02 is expecting a diff database format. The question now is "what is it?" and how do I get the UI to gen it. Supposedly the qpopper beta 3.1 has a new version of popauth that allows the password to be passed in for use in scripted situations. Maybe incorporating this into mail_apop_adduser would work? 

This is slowly driving me mad-----send help or its off to join Col. Kurtz

JP
--
--------------
|  Jerry Pape
|  jpape@xxxxxxxx
--------------