While trying to make a user entry in the /etc/passwd file unrecognized
so I could demonstrate the use of valid UIDs, I placed a # in front of the UID.
My theory was that this would make it an invalid number and cause Linux
to give an authentication failure. (This worked as expect on SunOS 4.1.4)
But then we tried to su to that user and were rewarded by being dumped
to UID 0. It didn't recognize the UID so it defaulted to 0. Cool huh?
It seems ideal for a hard to find, back door but given that you must be root
to write to the passwd file, I have not found a better way to really exploit it.
My friend replied:
I did test the problem using various remote logins, such as rlogin,
rsh, ftp, telnet, exec, ssh and console login. Trying to rlogin, rsh,
rexec or telnet failed with an authentication failure. But, su, ftp, ssh
and console login all succeeded and gave UID 0. A small stumbling block,
but still useful for a backdoor. I'll keep checking it tho'.
He also noted that it works the same for GID. We have not taken the time
to research the problem fully but have tested it on Red Hat 4.1 (2.0.27/2.0.30).
David Phillips, TASC
phillips@pcisys.net