Very Computer

Hi,

my setup:

- latest and greatest imap-2002d tarball
- slackware linux 9.0 using kernel 2.4.18 with shadow passwords
- imapd compiled with SSLTYPE=unix (to have plaintext auth with and without
SSL for testing)

Problem: Login with command

LOGIN watz watzpassword

always got rejected.

User "watz" was able to log in into the system with the above info just
fine.
His /etc/shadow entry looked like this:

watz:ShAdOwPAsS:0:0:99999:7:::0

Using gdb I could verify that c-client rejected the login in checkpw()
because

sp->sp_lstchg

was zero. This is obviously based on the idea expressed in the comment a few
lines above that code:

"lstchg last password change date if non-negative.  If zero, the user can
not log in without changing password."

However I was able to log in just fine with this user, no password change
needed. The user was created with the slackware admin tool on installation,
this is why the lastchange field is empty (its the initial pass and it has
never been changed and theres not really a need to because it was created
manually).

For testing I let this user change the password to something else, shadow
entry looked like this then:

watz:ShAdOwPAsS::12232:0:99999:7:::0

Now imapd would accept the LOGIN command above.
It may not actually be an imapd bug...but obviously the linux login behaves
different compared to the imapd login here. Linux login lets me in with no
password change needed anc c-lient locks me out.

It was a pretty confusing thing though since I never had troubles with the
plaintext LOGIN. This behaviour may be very confusing to other people also
since theres no obvious reason why imapd rejects the login.
If no action in c-client will be done I would suggest this behaviour gets at
least documented somewhere in the imapd FAQ.

Also...it would be nice to have some /var/log/mail lines dropped with a
reason why the passwords were rejected. Hmm although it might be readable
by ordinary users. Isn't there a way to have some diagnostic information
dropped somewhere without creating a security risk ?
Maybe some imapd command line option that would, if explicitely supplied
i.e. in inetd.conf, drop diagnostic info to /var/log/mail etc. ?
This would be extremely handy in situations like this.

Greetings,
Watz

Since there's no way to change passwords in IMAP, that's why imapd rejects
the login.  The assumption is that the date was set to zero for a reason.

Quote:> However I was able to log in just fine with this user, no password change
> needed. The user was created with the slackware admin tool on installation,
> this is why the lastchange field is empty (its the initial pass and it has
> never been changed and theres not really a need to because it was created
> manually).

It sounds like the authors of Slackware login decided not to enforce that
part of the specification.

Suppose that imapd didn't enforce it to match Slackware.  Then there would
be complaints that imapd had a security bug because it let people log in.

Quote:> It was a pretty confusing thing though since I never had troubles with the
> plaintext LOGIN. This behaviour may be very confusing to other people also
> since theres no obvious reason why imapd rejects the login.
> If no action in c-client will be done I would suggest this behaviour gets at
> least documented somewhere in the imapd FAQ.

That is a reasonable idea.

Do you know why it isn't in the FAQ?  This is the very first time that I
have heard that there is such a thing as a system that lets people log in
with sp_lstchg of zero without forcing a change password.  So obviously
it's not a very frequent FAQ... :-)

Quote:> Also...it would be nice to have some /var/log/mail lines dropped with a
> reason why the passwords were rejected. Hmm although it might be readable
> by ordinary users. Isn't there a way to have some diagnostic information
> dropped somewhere without creating a security risk ?

I think that you've identified the problem...

imapd is deliberately non-informative about the reason why it rejected a
password in order to stymie attackers.  The idea is "you have the source
code, if you really need to know what's going on you can edit this one
file and put in all the trace information you need."

That's the idea anyway.  It worked for you, but it doesn't work for people
who don't know the first thing about editing C programs.  But then again,
why should we make it easier for companies not to hire programmers?  :-)

Quote:> Maybe some imapd command line option that would, if explicitely supplied
> i.e. in inetd.conf, drop diagnostic info to /var/log/mail etc. ?

Unfortunately, this *very good* idea is precluded by a security package
that wants the command line for its own purposes... :-(

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Quote:> It sounds like the authors of Slackware login decided not to enforce that
> part of the specification.

Yes I think thats pretty possible. On the other hand...especially Slackware
is known for distributing pretty unchanged packages. I will try to figure
out why login lets me in with sp_lstchg=0. Maybe theres another condition
that enforces the password change and not sp_lstchg=0 alone by itself. Have
to experiment with that.

Quote:> Do you know why it isn't in the FAQ?  This is the very first time that I
> have heard that there is such a thing as a system that lets people log in
> with sp_lstchg of zero without forcing a change password.  So obviously
> it's not a very frequent FAQ... :-)

Yes I was surprised that noone yet had the same problem, especially since uw
imapd is the standard imapd (though sometimes older versions) on all linux
distributions I've used so far. However without the straight forward tip in
the FAQ to use gdb and simply break on on checkpw() and loginpw() I prolly
wouldn't have figured the problem out this fast.
So lets say the current FAQ still doesn't leave you alone with your problems
:)

Quote:> That's the idea anyway.  It worked for you, but it doesn't work for people
> who don't know the first thing about editing C programs.  But then again,
> why should we make it easier for companies not to hire programmers?  :-)

Ok I see the point hehe. But then...aren't there "administrator" jobs, too ?

Quote:

> > Maybe some imapd command line option that would, if explicitely supplied
> > i.e. in inetd.conf, drop diagnostic info to /var/log/mail etc. ?

> Unfortunately, this *very good* idea is precluded by a security package
> that wants the command line for its own purposes... :-(

Ugh..not sure what you're talking about...tcpd ?
You must be kidding...what package would prohibit additional command line
options for whatever it wraps?
I believe it would still be worth a thought....even just for those that
don't use the security package you mention.
Or for executing imapd in a shell. I think auth problems make a good share
of the problems ppl have with uw imapd, and this would offer a solution
besides debugging.

Anyway, I'll try to figure out why slackware lets me in with sp_lstchg=0,
and if theres a way to force a password change of that user through
something else with sp_lstchg still zero.

Thx,
Watz