UNIX file setuid sucurity hole?

Kha Sin Teow khasin at hcrvx2.UUCP
Sat Mar 14 07:33:53 AEST 1987


In article <2168 at ncoast.UUCP> robertd at 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.



More information about the Comp.unix.wizards mailing list