[comp.bugs.sys5] A security hole in getcwd

friedl@vsi.UUCP (Stephen J. Friedl) (03/06/88)

In article <388@koel.rmit.oz>, rcodi@koel.rmit.oz (Ian Donaldson) writes:
> in article <181@wsccs.UUCP>, terry@wsccs.UUCP (terry) says:
> > Do NOT write a setuid program that uses getcwd().  The getcwd() call
> > does a popen() of the "pwd" shell command and does not check it's path.This
> > means that someone could write their own pwd and execute the command from
> > their directory, thus gaining root access via a sh -c.
> 
> Since SVR2 getcwd() just takes the output of popen("pwd") it is safe in
> -that- regard.  There might of course be other security holes lurking 
> though.. since you -are- invoking a shell.

There *are* other holes, and popen("/bin/pwd") won't help either.
One solution some people use is to have getcwd() do a setuid(getuid())
after the fork but before the exec of the shell to keep pwd honest.
This fixes the security bug but doesn't work if the current directory
is only readable by the setuid user.

It is sad that something so "obvious" as getting the current
directory is as difficult under Unix as it is.
-- 
Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA   *Hi Mom*
CSNet: friedl%vsi.uucp@kent.edu  ARPA: friedl%vsi.uucp@uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl