Date: Sun, 11 May 1997 13:50:57 +0400 (MSD) From: Gnuchev Fedor <qwe@ht.eimb.rssi.ru> To: freebsd-security@FreeBSD.ORG Subject: Re: Linux UID/GID 'Feature' Message-ID: <Pine.BSF.3.95q.970511134602.168C-100000@ht.eimb.rssi.ru> In-Reply-To: <01BC5D8D.679DD4A0@frank56.pcisys.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Good morning, the text below is applicapable to FreeBSD as well. It's good enough to ftp and pick /etc/master.passwd, had not checked ssh. >On Sat, 10 May 1997, David Phillips wrote: > 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). > > > David Phillips, TASC > phillips@pcisys.net > With best regards Fedor Gnuchev mailto:qwe@ht.eimb.rssi.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970511134602.168C-100000>