> I mailed this to a friend as a sanity check:
>
>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)
Hi,
While that may be true on RedHat-4.1, it's not true for Linux running
the latest shadow package. I have tested all the above, in both #UID and #GID
cases, and what happens is that if you put a # in any of those fields in the
passwd entry, the user is ignored(no such user).
Shadow passwords for Linux exist for quite some time now, and have
become the default in operating systems like BSDi/Solaris/AIX, and IMHO,
the latest Linux releases should have been packaged with shadow passwording
by default.
Regards,
--Ariel
>
>
>David Phillips, TASC
> phillips@pcisys.net
>
+---------------------------------------------------------+
| Ariel Biener |
| e-mail: ariel@post.tau.ac.il Work ph: 03-6406086 |
+---------------------------------------------------------+