robertd@ncoast.UUCP (03/12/87)
It just accured to me that, thanks to the chown command and "setuid to owner when executing this C program" that no ones file is realy safe. I mean, couldn't someone who knows C alot write a program that is equivlent to "cat" that would display another users secret file. Then simply chmod the file to set to the owners ID apon execution? Then chown it to the owner. Then execute the command. Your uid will be set to the owner , who owns the file you wish to see. For instance, lets say there is a file called "foo", and John Smith owns the file. Now lets say that Peter Jones wants to see the file but can't, because he's not allowed. Now Peter can write a program called "xyz" that displays John's file. How ever, Peter still can't access it. Now, lets say,that Peter sets the permision on his program so that any one can access it, and the uid will be set to owner(Peter). Now Peter then can "chown" the command to John. The file now belongs to John. Then Peter executes the file. Since the file permisions says to change id to owner, Peters Id will be changed to John's id for the duration of the program. Now Peter will BE ALLOWED to read Johns file. How can you protect against this? [> Rd -- [=====================================] [ Rob DeMarco ] [ UUCP:decvax!cwruecmp!ncoast!robertd ] [ ] [ "bus error - passengers dumped" ] [=====================================]
haynes@ucbarpa.Berkeley.EDU.UUCP (03/13/87)
On our student machines we hack the kernel to prevent setting the setuid bit by a non-privileged user. If some user really needs it set he can request that of root. We don't get too many requests. I made this change reluctantly after finding the system riddled with hundreds of setuid shells that would let one user into another user's account. They were obtained by writing a game or other utility, inviting everyone to try it, and it had a secret side effect of creating a setuid shell. Jim Haynes haynes@ucscc.bitnet haynes@ucbarpa.berkeley.edu ...ucbvax!ucscc!haynes
pdb@sei.cmu.edu.UUCP (03/13/87)
In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes: > It just accured to me that, >thanks to the chown command and "setuid >to owner when executing this C program" >that no ones file is realy safe. > ... > How can you protect against >this? > Easy. Remember, unless you are the super-user, you can't use the chown command at all, not even to chown one of your own files. There are a number of reasons for that; the problem you pointed out is one of them. As it pointed out in the original Version 7 programmer's manual, if you were on a system with disk space accounting, if just anyone could chown stuff, you could subvert the accounting system. Of course, if you are running on a system which does allow random users to use chown (I've never heard of such a beastie, but just for the sake of argument...), I'd have have chown clear the 6000 bits of a file's protection as part of the chown process (and, of course, you couldn't reset them, since you can't chmod a file you don't own....) --Pat.
ssl@ptsfa.UUCP (03/13/87)
In article <695@aw.sei.cmu.edu.sei.cmu.edu> pdb@sei.cmu.edu.UUCP (Pat Barron) writes: >In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes: >> It just accured to me that, >>thanks to the chown command and "setuid >>to owner when executing this C program" >>that no ones file is realy safe. >> >Easy. Remember, unless you are the super-user, you can't use the chown command >at all, not even to chown one of your own files. Hold it, folks, what version of UNIX you guys are talking about. On AT&T's SVR2, we don't really have much problem. 'chown' is used to change ownership only, and 'chmod' is used to set file mode, setuid, sticky bit and stuffs. We can only 'chown' and 'chmod' by a file's owner, and 'chown' is smart enough to reset the suid bit when a file's ownership is released to another id. It came this way from AT&T, and we never had to hack with the kernel. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sam Lok San Francisco {ihnp4,pyramid,qantel}!ptsfa!ssl || To err is human, to really foul things I disclaim my disclaimer! || up requires super-user privilege!
ecl@mtgzy.UUCP (03/13/87)
In article <2168@ncoast.uucp>, robertd@ncoast.uucp (Robert DeMarco) writes: > I mean, couldn't someone who knows C alot write a program that is equivlent to > "cat" that would display another users secret file. Then simply chmod the > file to set to the owners ID apon execution? Then chown it to the owner. > Then execute the command. Your uid will be set to the owner , who owns the > file you wish to see. Then, article <1772@hi.uucp>, josh@hi.uucp (Josh Siegel) writes: > I cannot be sure but don't you have to be root to use chown? > If not, then yes... chown is a security hole. What operating > system are you using that allows this? Any operating system I have used (currently it's SVR2) unsets the setuid bits of a file when its ownership is changed. Evelyn C. Leeper (201) 957-2070 UUCP: ihnp4!mtgzy!ecl ARPA: mtgzy!ecl@rutgers.rutgers.edu
terryl@tekcrl.UUCP (03/13/87)
In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes:
+
+
+ It just accured to me that,
+thanks to the chown command and "setuid
+to owner when executing this C program"
+that no ones file is realy safe.
+
+ I mean, couldn't someone who
+knows C alot write a program that is
+equivlent to "cat" that would display
+another users secret file. Then simply
+chmod the file to set to the owners ID
+apon execution? Then chown it to the
+owner. Then execute the command. Your
+uid will be set to the owner , who owns
+the file you wish to see.
+
+
+ For instance, lets say there
+is a file called "foo", and John Smith
+owns the file. Now lets say that Peter
+Jones wants to see the file but can't,
+because he's not allowed.
+
+ Now Peter can write a program
+called "xyz" that displays John's file.
+How ever, Peter still can't access it.
+Now, lets say,that Peter sets the
+permision on his program so that any
+one can access it, and the uid will be
+set to owner(Peter). Now Peter then can
+"chown" the command to John. The file
+now belongs to John. Then Peter
+executes the file. Since the file
+permisions says to change id to owner,
+Peters Id will be changed to John's id
+for the duration of the program. Now
+Peter will BE ALLOWED to read Johns
+file.
+
+ How can you protect against
+this?
Well, for one thing, some flavors of UNIX do NOT allow normal mortal users
(i.e. people who are not root) to do a chown of a file. That's why chown is set-
user-id to root on these systems. But, there are some flavors that DO allow nor-
mal mortal users to do a chown of a file. Of all of the systems I've seen that
allow this, when the user does a chown of a file, the set-user-id bit is RESET,
i.e. it is no longer a set-user-id file. I've even seen some systems that always
reset the set-user-id bit, even if it is root that did the chown. Thus your
security hole is non-existant.
Terry Laskodi
of
Tektronixdjl@mips.UUCP (Dan Levin) (03/13/87)
On systems decended from USG, ie. SYSTEM III -> SYSTEM V.x.x, a user may use chown to "give away" a file. However, the setuid/setgid bits are cleared when you do so. On systems decended from BSD, ie. 4.0 BSD -> 4.3 BSD, a user may not use chown to give away a file, and so the problem is totally avoided. V6 was like BSD, I don't know about V7 (I assume since III is more related to V6 that V7 is like BSD too) nor about the research editions of more recent arrival (V8-V9). -- ***dan decwrl!mips!djl mips!djl@decwrl.dec.com
root@hobbes.UUCP (John Plocher) (03/13/87)
In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes: +---- | It just accured to me that, thanks to the chown command and | "setuid to owner when executing this C program" that no ones file | is realy safe. | [...] | ...set to owner(Peter). Now Peter then can "chown" the command to | John. The file now belongs to John. Then Peter executes the file. | Since the file permisions says to change id to owner, Peters Id | will be changed to John's id for the duration of the program. Now | Peter will BE ALLOWED to read Johns file. | | How can you protect against this? +---- Quoting from the SVR2 manual page for CHOWN(1): "If either command [chown,chgrp] is invoked by other than the super user, the set-user-ID and set-group-ID bits of the file mode, 04000 and 02000 respectively, will be cleared."
heiby@mcdchg.UUCP (03/13/87)
In article <695@aw.sei.cmu.edu.sei.cmu.edu> pdb@sei.cmu.edu.UUCP (Pat Barron) writes: > >Of course, if you are running on a system which does allow random users to >use chown (I've never heard of such a beastie, but just for the sake of >argument...), I'd have have chown clear the 6000 bits of a file's protection >as part of the chown process (and, of course, you couldn't reset them, since >you can't chmod a file you don't own....) I've heard of "such a beastie". It's called System V, and yes, it does clear the 6000 bits of the permissions. Quoting now from the "System V Interface Definition", Issue 2, Volume II, page 138: The command "chown" changes the owner of the "files" to "owner". The owner may be either a decimal user ID or a login name found in the password file. The command "chgrp" changes the group ID of the "files" to "group". The group may be either a decimal group ID or a group name found in the group file. If either command is invoked by other than the super-user, the set-user-ID and set-group-ID bits of the file mode will be cleared. This follows implicitly from the description of the "chown(BA_OS)" call, described in Volume I on page 65. Yes, System V and 4bsd have a different opinion of what should be done with chown by a non-super-user. No, I don't want to get into a religious argument. Yes, it will have to be worked out in the efforts to merge the two implementations. No, I don't know what they're going to do. BTW, this is also stated in almost identical language in the System V User's Reference. RTFM! -- Ron Heiby, mcdchg!heiby Moderator: mod.newprod & mod.os.unix Motorola Microcomputer Division (MCD), Schaumburg, IL "Save your energy. Save yourselves. Avoid the planet 'cuae2' at all costs!"
khasin@hcrvx2.UUCP (Kha Sin Teow) (03/14/87)
In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes: > It just accured to me that, >thanks to the chown command and "setuid >to owner when executing this C program" >that no ones file is realy safe. > > I mean, couldn't someone who >knows C alot write a program that is >equivlent to "cat" that would display >another users secret file. Then simply >chmod the file to set to the owners ID >apon execution? Then chown it to the >owner. Then execute the command. Your >uid will be set to the owner , who owns >the file you wish to see. > There are two types of user ids: real and effective. The effective id is the one that is used by the kernel to determine whether a particular process has any access rights to a resource. > > For instance, lets say there >is a file called "foo", and John Smith >owns the file. Now lets say that Peter >Jones wants to see the file but can't, >because he's not allowed. > > Now Peter can write a program >called "xyz" that displays John's file. >How ever, Peter still can't access it. >Now, lets say,that Peter sets the >permision on his program so that any >one can access it, and the uid will be >set to owner(Peter). Now Peter then can >"chown" the command to John. The file >now belongs to John. Then Peter >executes the file. Since the file >permisions says to change id to owner, >Peters Id will be changed to John's id >for the duration of the program. Now >Peter will BE ALLOWED to read Johns >file. > since "xyz" now belongs to John, the real user id of process shall be that of John, but the effective user id would still be Peter. Therefore Peter still cannot access the secret file, foo. Peter will be allowed to access foo via "xyz" if the "set-userID" bit of "xyz" has been set by John. Although Peter could have set it while the file belonged to him, the bit will be turned off as soon as he "chown" the file to John. (the same argument applies to the set-group ID) Therefore the security hole does not exist in this case. kha sin.
wcs@ho95e.UUCP (03/14/87)
In article <695@aw.sei.cmu.edu.sei.cmu.edu> pdb@sei.cmu.edu.UUCP (Pat Barron) writes: >In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes: >> [ setuid + chown is unsafe ] >Easy. Remember, unless you are the super-user, you can't use the chown command >at all, not even to chown one of your own files. On systems derived from V7 (V7, Berkeley 4.*, and maybe V8/V9), only the superuser can use chown. On System III, System V, and their derivatives, everyone can do chown, but chown turns off setuid. There were a few other holes that also had to be plugged, but they're "all" fixed. Chown is a tremendous convenience in a multi-person project; it makes it much easier to give files away. > if you were on a system with disk space accounting, if just anyone could > chown stuff, you could subvert the accounting system. This is still possible, but many accounting systems either don't charge for disk space, or charge for total blocks under $HOME. It's not usually a big problem, and if it becomes one, it's not hard to give each user a report of "files you own that aren't under your $HOME". -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
mwm@eris.UUCP (03/14/87)
Sigh. Much disinformation floating around about this. Straight data: 1) On BSD systems, only root can chown files. 2) On AT&T systems, you can give files away if you own them; root can chown files arbitrarily. Even then, the setuid & setgid bits are turned off if it isn't root doing the chown. The above can be found in the man pages for both systems. Perusing the source reveals: 3) On 4BSD systems, you can give a file to yourself without errors (odd, but probably because the chown system call subsumes the chgrp system call). If you aren't root, chown will turn off the setuid & setgid bits. Finally, it should be noted that the ability to give away files really mangles disk useage tracking, and creates major security holes elsewhere (do to bogosity in some system utilities). <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
guy@gorodish.UUCP (03/14/87)
> It just accured to me that, >thanks to the chown command and "setuid >to owner when executing this C program" >that no ones file is realy safe. Well, you're wrong. The "chown" command uses the "chown" system call. The "chown" system call either requires you to be the super-user, or turns of the set-UID and set-GID bits if executed by somebody other than the super-user, so you can't create a program that's set-UID to somebody other than yourself unless you're the super-user. This is all documented in the manual page for the "chown" system call, and would also be obvious if you actually tried "chown" on a set-UID program.
psfales@ihlpl.UUCP (03/14/87)
In article <695@aw.sei.cmu.edu.sei.cmu.edu>, pdb@sei.cmu.edu (Patrick Barron) writes: > > Of course, if you are running on a system which does allow random users to > use chown (I've never heard of such a beastie, but just for the sake of > argument...), I'd have have chown clear the 6000 bits of a file's protection > as part of the chown process (and, of course, you couldn't reset them, since > you can't chmod a file you don't own....) On my system which I assume is running more or less vanilaa AT&T UNIX (uname -a says "uts ihlpl 5.2.5 5 5890") it works exactly this way. I just tried copying /bin/cat to /tmp and making it setuid to me. That worked fine. Then I did a chown (random users can chown) to give it to someone else and the system cleared the setuid bit. Of course, this still does not address the trojan horse problem. -- Peter Fales UUCP: ...ihnp4!ihlpl!psfales work: (312) 979-7784 AT&T Information Systems, IW 1Z-243 1100 E. Warrenville Rd., IL 60566
ark@alice.UUCP (03/14/87)
In article <2168@ncoast.UUCP>, robertd@ncoast.UUCP writes: > Then simply > chmod the file to set to the owners ID > apon execution? Then chown it to the > owner. Then execute the command. Your > uid will be set to the owner , who owns > the file you wish to see. > Sorry, that doesn't work. Systems that allow non-privileged users to execute "chown" also turn off the set-uid bits when chown is executed.
guy@gorodish.UUCP (03/14/87)
>2) On AT&T systems, you can give files away if you own them;
A nit - on "USG" systems (System III, System V, and various other systems in
that line of descent), you can give files away if you own them. V6, V7, and
32V (from which 3BSD and 4BSD systems are derived) were also most definitely
AT&T systems, and they didn't allow you to give files away (so as not to
defeat (the non-existent) disk space accounting procedures, claimed the
manual).kdavies@dalcsug.UUCP (03/15/87)
In article <1772@hi.uucp> josh@hi.UUCP (Josh Siegel) writes: > >I cannot be sure but don't you have to be root to use chown? > Under Xenix 5, I believe BSD does as well, chown can be executed by anyone, BUT, when they do a chown on a file, any setuid permissions on the file are cleared when it puts in the new owner. Then only the NEW owner can set the setuid again. Not sure what happens if there is a setgid, and the original owner and the new owner are of different groups. I would suspect that it would clear the setgid bits (but we can't _assume_ around here :-) --------------------------------------------------------------- Kevin Davies ...{seismo|watmath|utai|garfield} !dalcs!dalcsug!kdavies Kirk : "Spock, I do wish you'd stop using those colourful metaphors" Spock: "The _hell_ I will, Captain" ---------------------------------------------------------------
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/17/87)
In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes: > I mean, couldn't someone who >knows C alot write a program that is >equivlent to "cat" that would display >another users secret file. Then simply >chmod the file to set to the owners ID >apon execution? I assume you're discussing the AT&T (System V) family of UNIX, since on others you are not able to chown a file without being super-user. According to the manual, which you should read, "If chown is invoked successfully by other than the super-user, it clears the set-user-ID and set-group-ID bits of the file-mode." So your trick doesn't work.
paul@devon.UUCP (Paul Sutcliffe Jr.) (03/17/87)
In article <695@aw.sei.cmu.edu.sei.cmu.edu> pdb@sei.cmu.edu.UUCP (Pat Barron) writes: [ reguarding the chown command ] > Of course, if you are running on a system which does allow random users to > use chown (I've never heard of such a beastie, but just for the sake of > argument...), I'd have have chown clear the 6000 bits of a file's protection > as part of the chown process (and, of course, you couldn't reset them, since > you can't chmod a file you don't own....) Can't speak for all Un*x systems (how *do* you say the plural of Unix!), but Xenix's chown does this. Quoting from the manual: "If chown is invoked by other than the super-user, the set-user-ID and set-group-ID bits of the file mode, 04000 and 02000 respectively, will be cleared." Also, you must either be the super-user or the owner of the file in order to chown it. - paul -- Paul Sutcliffe, Jr. paul@devon.UUCP (or, if you prefer:) Devon Computer Services {seismo,ihnp4,allegra,rutgers}!cbmvax!devon!paul Allentown, PA "I love work. I could sit and watch people do it all day!"
tim@ism780c.UUCP (Tim Smith) (03/18/87)
Things could get really confusing with Sys V release 3. Chown is handled through the file system switch. Explaining to a user who is new to computers why he/she can chown some files without being root, but must be root to chown some other files, and can't chown some files even as root, would be interesting. -- Tim Smith Welcome to Wackyland uucp: sdcrdcf!ism780!tim "It can happen here" Compuserve: 72257,3706 Pop: 100 nuts and a squirrel Delphi or GEnie: mnementh
amos@instable.UUCP (Amos Shapir) (03/18/87)
In article <15046@sun.uucp> guy@sun.UUCP (Guy Harris) writes: > [the old Unix systems] didn't allow you to give files away (so as not to >defeat (the non-existent) disk space accounting procedures) How typical! Since disk accounting did not exist, AT&T have removed the restriction on 'chown'; the Berkley guys went on and implemented the whole disk accounting package... (To give credit where it's due - the disc [sic] accounting was originally written at UNSW, Australia). -- Amos Shapir National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel (011-972) 52-522261 amos%nsta@nsc.com 34.48'E 32.10'N
guy%gorodish@Sun.COM (Guy Harris) (03/19/87)
>> [the old Unix systems] didn't allow you to give files away (so as not to >>defeat (the non-existent) disk space accounting procedures) > >How typical! Since disk accounting did not exist, AT&T have removed the >restriction on 'chown'; the Berkley guys went on and implemented the whole >disk accounting package... What's *really* funny is that the USDL UNIXes have a rather elaborate set of accounting procedures that include disk space accounting; V7 did add the "quot" command to do disk space accounting, but I presume nobody used it so there were no disk space accounting procedures (as opposed to disk space accounting programs). So the systems that permitted you to give files away were the ones that had disk space accounting, and the ones that didn't were the ones that didn't have disk space accouniting. Actually, I think the restriction was lifted in PWB/UNIX (the manual pages don't explicitly refer to such a restriction), which didn't have disk space accounting (at least I couldn't find anything obvious in section VIII (sic)).