Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!rutgers!mtune!petsd!pedsga!chip
From: chip@pedsga.UUCP
Newsgroups: comp.bugs.sys5
Subject: Re: A security hole
Message-ID: <357@pedsga.UUCP>
Date: 8 Mar 88 23:24:53 GMT
References: <181@wsccs.UUCP> <388@koel.rmit.oz>
Reply-To: chip@pedsga.UUCP (Chip Maurer,7361)
Organization: Concurrent Computer Corp., Tinton Falls, N.J.
Lines: 31
Keywords: shell, secure

In article <388@koel.rmit.oz> rcodi@koel.UUCP 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.
>
>This would be a hole if your system had the BSD /bin/sh, but in the SVR2
>/bin/sh, the "pwd" command is a built-in and always executes the same way 
>regardless of any PATH setting or the contents of the current directory.  

Mild flames accepted for the following statement:

"Nothing which is 'builtin' to the shell is guarenteed to stay builtin."

Since many (okay some) UNIX sites also have a source license, if you 
recompile the shell after altering msg.c (change the "pwd" builtin to 
"_pwd" or whatever), then it seems that a call to getcwd would execute 
the pwd in your carefully, although mischiefously (is that a word?) 
setup path to get the desired root privileges.

EAT
THIS
INEWS
!!!!!
!!!!!
-- 
         Chip ("My grandmother called me Charles once. ONCE!!") Maurer
     Concurrent Computer Corporation, Tinton Falls, NJ 07724 (201)758-7361
        uucp: {mtune|purdue|rutgers|princeton|encore}!petsd!pedsga!chip
                       arpa: pedsga!chip@UXC.CSO.UIUC.EDU