A security hole in getcwd()

Stephen J. Friedl friedl at vsi.UUCP
Sun Mar 6 08:00:39 AEST 1988


In article <388 at koel.rmit.oz>, rcodi at koel.rmit.oz (Ian Donaldson) writes:
> in article <181 at wsccs.UUCP>, terry at 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 at kent.edu  ARPA: friedl%vsi.uucp at uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl



More information about the Comp.bugs.sys5 mailing list