>I don't have the time to look into this much further, but it definitely
>looks scarey. I've tried it on 3 machines, and they all produce the
>same results.
...
>[alex@machine /tmp]$ ./pass
>[alex@machine /tmp]$ chfn -f $BUFF -p $BUFF -h $BUFF -o $BUFF
>Changing finger information for alex.
>Password:
>Finger information changed.
This is an interesting question; "chfn" used to be a horrible security
hole on BSD back in the '80s permitting all sorts of fun and games....
Judicious adjustment of the length of the GECOS field permitted people
to tickle a bug in the way password records were processed, such that
it appeared to programs doing "getpwnam()" and family that an extra line:
::
...or similar existed in the password file, and so doing
% su ""
...allowed a user to "su" to the <empty username> with <empty uid == 0>
IE: the equivalent of "su root".
It is the memory of this sort of shenanigans that drove me to issuing
a patch for CrackLib so quickly in case similar was possible.
>[alex@machine /tmp]$ wc /etc/passwd
> 26 29 2068 /etc/passwd
>
>** At this point, the passwd entry for 'alex' is >48k long **
I found similar syndromes manually extending my GECOS field under
Solaris using EMACS, when testinbg the CrackLib patch; anything over
1Kb total record size, perhaps smaller, and my username ``vanished''.
The question, I suppose, is: whose fault is it?
At what point does a password file entry become "ridiculously long"?
My take on this is that allowing users to have "chfn" or any similar
function which modifies the password file is a "bad thing" (yes, in
certain circumstances, I extend this theory to "/bin/passwd" too) and
that the response of sysadmins to users whining about lack of "chfn"
(which you deleted for security reasons) should be expressed by staring
them in the eye, saying "hard cheese", and fingering a cricket bat ominously...
- alec
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:37:03 PDT