Security hole in AIX 3.1

[David H Close]

I have encountered two problems with password administration under AIX 3.1.
IBM acknowledges both and promises a fix for one of them.  However, the other
they say works as intended; no fix will be made.  As that problem presents
a security hole, I was very surprised.  Judge for yourself:

Problem 1 is a catch 22.  In /usr/security/login.cfg, you can specify a
minimum time between password changes.  This is intended (I believe) to
prevent a user, forced to change his password periodically, from immediately
changing it back to the former value.  The default for this MINAGE parameter
is 0.  If you change it to a positive value (measured in weeks), you will be
unable to add a new user properly.

This is because, when you add a new user, you must use passwd (or smit, same
thing) to assign the user's initial password.  This sets the ADMCHG flag in
/usr/security/passwd, forcing the user to change his password on his first
login.  But, when he tries to do so, the system refuses the change since it
hasn't been long enough since *you* changed his password to give him the
initial value.  He can't login!  IBM does acknowledge that this is a bug.
The only workaround at this time is to set MINAGE to 0, at least temporarily.

Problem 2 is related to problem 1.  If the ADMCHG flag is set, the system
is supposed to force the user to change his password before he can login.
It does if he tries the login via a serial port.  It DOESN'T if he tries
via telnet over TCP/IP.  A naive user may not notice the omission and neglect
to ever change his password, thus compromising security.  I was told that
this problem was initially reported back in July and closed immediately.
Closure was because "that's the way telnet works on BSD, and we can't chance
breaking things by changing telnet."  

I don't understand.  Telnet doesn't do the login, getty/login does.  This
seems analogous to saying that a DEC terminal doesn't check your password
so we can't make you do so if you are using a DEC terminal.  Since the present
situation effectively neutralizes the entire password management feature,
it seems to me that IBM should WANT to fix it.  But I've been told that
it can only be changed by an RPQ.  What do you think?

Both of these problems have been repeated by the IBM porting center using
the latest 3001 update.

Dave Close, Compata, Arlington, Texas
compata at cup.portal.com
compata at mcimail.com