From owner-freebsd-security Sun May 11 02:49:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA20589 for security-outgoing; Sun, 11 May 1997 02:49:09 -0700 (PDT) Received: from ht.eimb.rssi.ru (ht.eimb.rssi.ru [193.232.192.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA20584 for ; Sun, 11 May 1997 02:49:05 -0700 (PDT) Received: from localhost (qwe@localhost) by ht.eimb.rssi.ru (8.8.5/1997.05.04) with SMTP id NAA00472 for ; Sun, 11 May 1997 13:50:57 +0400 (MSD) Date: Sun, 11 May 1997 13:50:57 +0400 (MSD) From: Gnuchev Fedor Reply-To: Gnuchev Fedor To: freebsd-security@FreeBSD.ORG Subject: Re: Linux UID/GID 'Feature' In-Reply-To: <01BC5D8D.679DD4A0@frank56.pcisys.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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