bull@itd.nrl.navy.mil (07/25/90)
We at the Naval Research Laboratory are investigating security flaws in software. Our goal is to collect examples of actual flaws and provide descriptions of them in a form that could help software developers avoid or eliminate such flaws in future products. We do not intend to distribute descriptions of flaws in a form that would be useful to penetrators. In November of 1988 a flaw was described in the unix-wizards bulletin board dealing with the rlogin program. It seems that in some unix systems it was possible for a user to gain superuser access to the system by giving the command "rlogin host-name -l ''". We have not been able to determine the specific flaw that permitted this security breach, and we would appreciate any information readers of this message can provide on this point. Thanks in advance Alan R. Bull bull@itd.nrl.navy.mil (202) 767-6698 ----- End Included Message -----
schlake@nmt.edu (William Colburn) (07/25/90)
In article <23959@adm.BRL.MIL> bull@itd.nrl.navy.mil writes: > >In November of 1988 a flaw was described in the unix-wizards bulletin >board dealing with the rlogin program. It seems that in some unix systems it >was possible for a user to gain superuser access to the system by giving >the command "rlogin host-name -l ''". We have not been able to determine >the specific flaw that permitted this security breach, and we would >appreciate any information readers of this message can provide on this point. > Well, a freind of mine here was rloging into a SUN 3/50 from a terminal server. He got the login prompt, and then decided not to login that particular machine, so hit cntl-C cntl-D (or the reverse, I don't remember). Rather than terminating the connection, he got a prompt. `whoami` returned "root". The real root found no login records, no `lastcomm` records, no nothing. The problem only existed on that single sun machine, from the specific terminal server. They deleted the 'yp' (copyright? phfffbbbt!) entry and the problem went away. Schlake Sys-admin Nethack player and a lousy speller.
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/26/90)
In article <23959@adm.BRL.MIL> bull@itd.nrl.navy.mil writes: >In November of 1988 a flaw was described in the unix-wizards bulletin >board dealing with the rlogin program. It seems that in some unix systems it >was possible for a user to gain superuser access to the system by giving >the command "rlogin host-name -l ''". We have not been able to determine >the specific flaw that permitted this security breach, and we would >appreciate any information readers of this message can provide on this point. This is not a flaw in "rlogin"/rlogind as such, but rather a reflection of the fact that many BSD-based systems would create an /etc/passwd entry ::0:0::: when updating passwords, etc., if there happened to be an incorrectly- formatted entry in the file. The actual bug was in a library function, and has been fixed in UNIX System V implementations for many years now.
djm@eng.umd.edu (David J. MacKenzie) (07/26/90)
Mike Rowan, who wrote the GNU login (still in test stage) sent me a note recently that might be relevant here, excerpted below: On a standard 4.3 login system write a program that does this: fork() & exec login write to login's stdin: locuser\0remuser\0tty/speed\0 So I login to a host and run this like so: exec "login -r localhost" and stick this on logins stdin: "root\0root\0sun/9600" And I get a root shell. They took this auth code out of login in 4.3T and make rlogind do it. -- David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
dzenc@gnu.ai.mit.edu (Dan Zenchelsky) (07/26/90)
In article <DJM.90Jul25190101@frob.eng.umd.edu> djm@eng.umd.edu (David J. MacKenzie) writes: > >So I login to a host and run this like so: >exec "login -r localhost" >and stick this on logins stdin: "root\0root\0sun/9600" > >And I get a root shell. They took this auth code out of login in 4.3T >and make rlogind do it. Except that all of the logins I've seen make sure getuid()==0 before allowing this to happen. So, the only way to do this is to already be root. >-- >David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu> -Dan -- ___________________________________________________________________________ | _______ |________________________________________| | || |o| Dan Zenchelsky | | | ||____| | | Any sufficiently advanced bug is | | | ___ | dzenc@gnu.ai.mit.edu | indistinguishable from a feature. | | |_|___|_| |______________-- Rich Kulawiec__________| |__________________________________|________________________________________|
rt@msor.UUCP (Raymond Thompson) (07/26/90)
In article <23959@adm.BRL.MIL> bull@itd.nrl.navy.mil writes: >We at the Naval Research Laboratory are investigating security flaws in >software. Our goal is to collect examples of actual flaws... > ... It seems that in some unix systems it >was possible for a user to gain superuser access to the system by giving >the command "rlogin host-name -l ''". This happened to me soon after we installed a new SUN system and was caused by a typing error in the passwd file. The line +::0:0::: forcing a look at NIS (ne YP) was typed in with the leading '+' missing. Hey presto, a null System Manager
dave@galaxia.Newport.RI.US (News Administrator) (07/28/90)
In article <698@msor0.UUCP> rt@msor0.UUCP (Raymond Thompson) writes: > >This happened to me soon after we installed a new SUN system and was caused >by a typing error in the passwd file. The line >+::0:0::: >forcing a look at NIS (ne YP) was typed in with the leading '+' missing. >Hey presto, a null System Manager This is a good example of why I never use "0" in a YP reference, I always use "999". That way, if anything goes wrong the worst that can happen is that someone can gain access to the machine using the uid 999. Since I also make sure that I never assign 999 to a real user there is very little damage that can be done. About the worst thing that can happen is that the intruders could copy the passwd file so that they could munch on it later but if you use shadow passwords then even that is not a problem. -- David H. Brierley Home: dave@galaxia.Newport.RI.US Work: dhb@quahog.ssd.ray.com Be excellent to each other.