🚀 go-pugleaf

In article <181@wsccs.UUCP> terry@wsccs.UUCP (terry) writes:
>
>	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.

I am not sure this is a real problem.  As far as I know, pwd is built in
the standard sys V shell.  Whenever you try to execute pwd, the builtin
command is executed, even if there is another pwd in your path.

The only way to execute another pwd is to give explicitely its full
pathname (ex: ./pwd), so I think that getcwd() is quite secure.
Obviously, the problem could exist if /bin/sh were not the standard sys V
shell.
-- 
Gilles BERGER SABBATEL
IMAG-TIM3/INPG, 46 Avenue Felix Viallet, F-38031 GRENOBLE CEDEX - FRANCE
Tel: 76 47 98 55 Ext: 606
UUCP: ...!seismo!mcvax!inria!archi!berger or: berger@archi

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.  

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.

[So much for the concept of "keeping the shell simple and small"...]

In the BSD /bin/sh, pwd is not a built-in, and you would receive the
described behaviour.  But in BSD the equivalent to SVR2 getcwd(3) is 
getwd(3), and this doesn't use popen(3) or /bin/sh, so doesn't have 
this problem.  Its also much much faster.  Try issuing the SVR2 getcwd()
function from a program that has a 4Mb data segment and you will see
what I mean (on systems that don't have copy-on-write fork()'s).

Ian D

In article <2613@imag.UUCP> berger@imag.UUCP (Gilles BERGER SABBATEL) writes:
|In article <181@wsccs.UUCP> terry@wsccs.UUCP (terry) writes:
|>
|>	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.
|
|I am not sure this is a real problem.  As far as I know, pwd is built in
|the standard sys V shell.  Whenever you try to execute pwd, the builtin
|command is executed, even if there is another pwd in your path.
|
|The only way to execute another pwd is to give explicitely its full
|pathname (ex: ./pwd), so I think that getcwd() is quite secure.
|Obviously, the problem could exist if /bin/sh were not the standard sys V
|shell.
|-- 
|Gilles BERGER SABBATEL
|IMAG-TIM3/INPG, 46 Avenue Felix Viallet, F-38031 GRENOBLE CEDEX - FRANCE
|Tel: 76 47 98 55 Ext: 606
|UUCP: ...!seismo!mcvax!inria!archi!berger or: berger@archi


This IS a security hole and it has nothing to do with if pwd is
built in or not. I will NOT explain in detail how you do. Terry
didn't see the real security hole.


Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Tel:     +46-920-91677  (work)                 +46-920-48390  (home)
UUCP:    {uunet,mcvax}!enea!cad.luth.se!sow
Internet: sow@cad.luth.se

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

In general: using system(3) or popen(3) inside a set-uid-on-exec
program is a severe security violation. Please believe guys
how know about it. If I would tell why, everybody could crack a
SVR2 within a four-line shell script! AT&T did a lot for
fixing this security hole in SVR3.*

For the same reason set-uid shell scripts should be outlawed (in BSD4.*).
Note, that getcwd(3) still calls popen("/bin/pwd" ...). Use getpwd()
if this routine is available.

In article <181@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes:
> 
> 	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.

First of all, by writing a setuid program you automatically open
the security hole and you are likely to fall in. You must always
be suspicious of any setuid program.

Second, when you really need a setuid program you'll have to check a lot
of permissions etc. yourself. One system call was created to help you with
access permissions: access(2). access(2) uses the real user IDs instead
of the effective user IDs when checking access permissions. (Remember that
a setuid program only changes the effective user ID of the calling process.)

________________________________________________________________
Martien F. van Steenbergen
National Institute of Public Health and Environmental Protection
dept. RIVM/CCE
PO Box 1
3720 BA Bilthoven
The Netherlands

tel: (31) 30 742819
email: ...!mcvax!rivm!martien
___________________________MSDOSN'T_____________________________

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

In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
> In article <181@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes:
> > 
> > 	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.
> 
> First of all, by writing a setuid program you automatically open
> the security hole and you are likely to fall in. You must always
> be suspicious of any setuid program.

Uh, I'm not sure I believe all this.  I mean, I understand why root should
never include "." or any world-writable directories in its search path.
Does your unspecified hole amount to anything more than this?  If so, you
aren't saying anything at all about getcwd() or popen(), just about search 
paths.

> Second, when you really need a setuid program you'll have to check a lot
> of permissions etc. yourself. 

This adds to my conviction that someone doesn't know what they're talking
about.  Do you perhaps mean "setuid-root"?  If so, you are of course correct.
If you don't understand my point, you don't know enough about Unix security
to pontificate on the subject.

Also, I'm sure that I'm far from the only one who is getting tired of seeing
dire warnings like:
	The 'cc' command contains a MAJOR security hole; you should delete it
	from your system as fast as possible.  I can't tell you what the hole
	is, because it would allow any hacker to break into any Unix system in
	the world.  Believe me; I know what I'm talking about.
It's easy enough to make up warnings like these, but many of them turn out
on investigation to be full of bull; some are in fact fraudulent attempts
to discredit someone else's useful software.

Anyhow, what can one do with getcwd() or popen() within a setuid program
(root or otherwise) that isn't a consequence of the search path?  If there
is a real security hole here, I'd be very interested in reading about it.

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
> Second, when you really need a setuid program you'll have to check a lot
> of permissions etc. yourself. One system call was created to help you with
> access permissions: access(2). access(2) uses the real user IDs instead
> of the effective user IDs when checking access permissions. (Remember that
> a setuid program only changes the effective user ID of the calling process.)

comp.unix.wizards has had several recent postings on access(2).
Many people use access(2) incorrectly and it causes no end of
difficulty for those writing restricted setuid or setgid systems.
Send me a note if you want a copy of my near-flame on this with
info on how *not* to use it.

     Steve
-- 
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

In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
 > > [somebody else's stuff (sorry, deleted it)]
 > > First of all, by writing a setuid program you automatically open
 > > the security hole and you are likely to fall in. You must always
 > > be suspicious of any setuid program.
 >
 > Uh, I'm not sure I believe all this.  I mean, I understand why root should
 > never include "." or any world-writable directories in its search path.
 > Does your unspecified hole amount to anything more than this?  If so, you
 > aren't saying anything at all about getcwd() or popen(), just about search
 > paths.

You can never remind people enough about search paths because it
is so easy to mess up.  Also, it is not "obvious" that asking the
system for your current directory will fork another process while
doing so.  Set[ug]uid programs should do something like:

        putenv("PATH=/bin:/usr/bin:/etc");

early so the user's path is totally ignored no matter what the
rest of the program does.  Sometimes perhaps you can't do this
but in most cases it will help a lot.

 > This adds to my conviction that someone doesn't know what they're talking
 > about.  Do you perhaps mean "setuid-root"?  If so, you are of course correct.
 > If you don't understand my point, you don't know enough about Unix security
 > to pontificate on the subject.

Hold it.  If I find a breakable setuid program on a machine I
will get root eventually.  Example: if I break the "bin" group on
a machine where /bin is drwxrwxr-x (like my SVR3.1 3B2/400)  I can
replace /bin/ls with my own program.  My version will exec the
"real" ls but if root is the uid then it will do something
special for me.  Setuid/setgid *anything* is dangerous.

 > Also, I'm sure that I'm far from the only one who is getting tired of seeing
 > dire warnings like:
 >      The 'cc' command contains a MAJOR security hole; you should delete it
 >      from your system as fast as possible.  I can't tell you what the hole
 >      is, because it would allow any hacker to break into any Unix system in
 >      the world.  Believe me; I know what I'm talking about.
 > It's easy enough to make up warnings like these, but many of them turn out
 > on investigation to be full of bull; some are in fact fraudulent attempts
 > to discredit someone else's useful software.

We all hate them, partly because we would *love* to know what the
bug is (of course *we* would never misused this information).
Too bad there aren't good ways to fix the bugs without giving a
class in smashing systems.  The best you can do is consult your
friendly neighborhood security wizard and ask him/her about it.
They are perhaps more capable of evaluating the nature of the
threat.

 > Anyhow, what can one do with getcwd() or popen() within a setuid program
 > (root or otherwise) that isn't a consequence of the search path?  If there
 > is a real security hole here, I'd be very interested in reading about it.

Even if a program does

        system("/bin/pwd");

it can still be smashed, partially related to the search path.
See the last item on the list for the fix.

These rules have probably been posted a hundred times but I
don't mind doing it one more.

*    don't write setuid programs

*    if you must, don't make them setuid root.  Make them some
     new uid/gid that is not part of the system (avoid bin, sys,
     adm, etc.)

*    write setgid instead of setuid if you can

*    if the special access is in a limited area, write a separate
     program that does just that job and make the rest of the
     program non-set-anything.  Then have the main program call
     the setuid guy for the secure stuff.  Example: /bin/mv is
     normal but calls (setuid root) /usr/lib/mv_dir to move
     directories around.

*    open all your secure files early in the program, then do

         setuid(getuid());
         setgid(getgid());

     This turns off the setuid/setgid permissions and makes the
     program a normal peon user process again.  Remember, once a
     file is open permissions don't count any more.

*    if you must run set[ug]id all the time, write your own
     system() that does the previous item after the fork but
     before the exec.  This makes the child not have any special
     permissions. It doesn't always help if you need to exec
     a protected process in a protected areA, but it works in
     a lot of cases.

*    If your programs call popen or system, put the line

          putenv("IFS= \n\t");

     in it early.  This closes up a fairly obscure hole; read your
     /bin/sh manual if you are really interested in this.  Ask
     your local security wizard about this for more info.


     One thing about security is that there is always somebody
out there who knows more than you do, and all they need is one
bug that you didn't think of.  The above list is certainly not
all-inclusive, and the security wizards out there are welcome to
flame me (privately unless it is of general interest) if I blew
it on something.

     Steve
-- 
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

In article <478@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
...
>
>Anyhow, what can one do with getcwd() or popen() within a setuid program
>(root or otherwise) that isn't a consequence of the search path?  If there
>is a real security hole here, I'd be very interested in reading about it.

There is a nice hack to make the sh misunderstood the path variable.
For example the following will work on most SYSV machines:
in file named ``bin'' in your cwd:

IFS=" \t\n" # escapes for readability
/bin/sh </dev/tty >/dev/tty 2>&1
pwd

and now from a command line:
IFS="/"; export IFS
at now + 1 minute # or any setuid root containing getcwd

This will not work with the Korn shell, there is a special check for IFS.
-- 
Jens-Uwe Mager
jum@focus.UUCP || jum@cosmo.UUCP

In article <357@pedsga.UUCP>, chip@pedsga.UUCP writes:
> Mild flames accepted for the following statement:

OK, here's a flick of my Bic.

# "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.

If you can replace /bin/sh you already have privileges (and /bin/sh is
surely not the only or even the easiest place a system cracker could plant
a Trojan horse under those circumstances), or a system admin was verrrry
careless with permissions on /bin or /bin/sh.  If you have your own doctored
copy of "sh" it does you no good if it isn't in /bin/sh.  (popen explicitly
uses "/bin/sh").
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
| AT&T Computer Systems Division |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|

In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
> In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
> > First of all, by writing a setuid program you automatically open
> > the security hole and you are likely to fall in. You must always
> > be suspicious of any setuid program.
> 
> Uh, I'm not sure I believe all this.  I mean, I understand why root should
> never include "." or any world-writable directories in its search path.
> Does your unspecified hole amount to anything more than this?  If so, you
> aren't saying anything at all about getcwd() or popen(), just about search 
> paths.

What I am trying to say is that you must be careful writing setuid-root
(C etc.)) programs.
So many already fell into the security hole. You cannot warn them
enough. Perhaps there exists a book which describes a lot of Unix security
related topics. I'd love to have one.

> > Second, when you really need a setuid program you'll have to check a lot
> > of permissions etc. yourself. 
> 
> This adds to my conviction that someone doesn't know what they're talking
> about.  Do you perhaps mean "setuid-root"?  If so, you are of course correct.

Of course I mean setuid-root (sorry).

> If you don't understand my point, you don't know enough about Unix security
> to pontificate on the subject.

I do understand your point.
You're right, I should be more careful stating my opinions.

> Also, I'm sure that I'm far from the only one who is getting tired of seeing
> dire warnings like:
> 	The 'cc' command contains a MAJOR security hole; you should delete it
> 	from your system as fast as possible.  I can't tell you what the hole
> 	is, because it would allow any hacker to break into any Unix system in
> 	the world.  Believe me; I know what I'm talking about.
> It's easy enough to make up warnings like these, but many of them turn out
> on investigation to be full of bull; some are in fact fraudulent attempts
> to discredit someone else's useful software.

That's true, but since the Unix market and its user is growing rapidly,
there are a lot of unexperienced `system managers', who will fall into the
security hole. I think any help is welcome for those persons.
If you're tired of reading those warning, then don't read them!
(You read mine |->)

________________________________________________________________
Martien F. van Steenbergen
National Institute of Public Health and Environmental Protection
dept. RIVM/CCE
PO Box 1
3720 BA Bilthoven
The Netherlands

tel: (31) 30 742819
email: ...!mcvax!rivm!martien
________________________________________________________________

In article <379@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
|In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:

| > dire warnings like:
| >      The 'cc' command contains a MAJOR security hole; you should delete it
| >      from your system as fast as possible.  I can't tell you what the hole
| >      is, because it would allow any hacker to break into any Unix system in
| >      the world.  Believe me; I know what I'm talking about.
| > It's easy enough to make up warnings like these, but many of them turn out
| > on investigation to be full of bull; some are in fact fraudulent attempts

Umm, if I remember my history lessons correctly, this *intentionally
coded* bug was only in an early version of the ritchie compiler, and
not in pcc.  Please don't delete cc. (at least not yet; gnu cc is
still in beta test :-)

In article <892@cosmo.UUCP> jum@cosmo.UUCP (Jens-Uwe Mager(sysop)) writes:
>This will not work with the Korn shell, there is a special check for IFS.

I couldn't find any valid reason for importing IFS, so the BRL Bourne
shell resets it to the default value at the beginning of a shell script.

>So many already fell into the security hole. You cannot warn them
>enough. Perhaps there exists a book which describes a lot of Unix security
>related topics. I'd love to have one.
>

Yes there is: 

Unix System Security
by Patrick H. Wood and Stephen G. Kochan

(From the back)

Here is a practical guide to computer security on the Unix system for the
user, administrator, or potenial Unix buyer.  It will teach you 
everything you need to know to make your system secure and keep it
that way.  Topics covered include:

* file and directory permissions

* password security

* how the setuid/gid permissions work and how to use them

* How the various security-related Unix commands and functions work

* how to write secure programs

* different methods of data encryption - including the government
  standard DES algorithm -- and how secure they are

* data encryption over communication networks

* how to discover and plug potenial security holes in your system

* how to periodically monitor your system to maintain security

Also included is the complete surce for several security auditing and 
administration programs.

<end of back cover>

If you are a novice this will give you a cookbook guide to security and
if you are a wizard it will be a good spring board for better programs
to improve your security.  In my security seminar I aways recommend that
they get a copy.  It the best investment in security that you can make.
-- 
Darryl Wagoner		dpw@unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (512)-255-8751 (home) (512)-823-3774
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!dpw

In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
> 
> Uh, I'm not sure I believe all this.  I mean, I understand why root should
> never include "." or any world-writable directories in its search path.
> [stuff]  If so, you
> aren't saying anything at all about getcwd() or popen(), just about search 
> paths.
> 
> Anyhow, what can one do with getcwd() or popen() within a setuid program
> (root or otherwise) that isn't a consequence of the search path?  If there
> is a real security hole here, I'd be very interested in reading about it.
> 
> John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

Root's search path has nothing to do with setuid-root programs - they
get their path from the process that invokes them, so you don't have any
control over the search path (unless you explicitly change it in your
setuid program - but how many people think of doing that?)

--
Mark Buda, The Embattled Hermit          Domain: hermit@chessene.uucp
Dumb: ...{rutger,ihnp4,cbosgd}!bpa!vu-vlsi!devon!chessene!hermit
"Dr. Johnson, can you come over right away? My father has a hibachi on his
head."

In article <722@rivm05.UUCP>, Martien F v Steenbergen writes:
> First of all, by writing a setuid program you automatically open
> the security hole and you are likely to fall in. You must always
> be suspicious of any setuid program.

	Not if you program it correctly.  The point was that the security was
not checked by specification of the execution path, and it should have been,
as getcwd() is a library routine.

> Second, when you really need a setuid program you'll have to check a lot
> of permissions etc. yourself. One system call was created to help you with
> access permissions: access(2). access(2) uses the real user IDs instead
> of the effective user IDs when checking access permissions. (Remember that
> a setuid program only changes the effective user ID of the calling process.)

	The access() call is a kludge.  I could do that anyway with the
following:

	system( "/bin/sh -c <command>");

	Where <command> is the command I want run with the _real_ UID and GID.
Remember that the child inherits the parents effective as it's real, if it's
done this way.  This is helpful for running things which make sure you're
root before they will run.

> ___________________________MSDOSN'T_____________________________

I can't argue with you here... :-)

				Terry Lambert
				terry@wsccs

In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
} In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
} In article <181@wsccs.UUCP>, I write:
} > 
} > 	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.
} 
} Also, I'm sure that I'm far from the only one who is getting tired of seeing
} dire warnings like:
} 	The 'cc' command contains a MAJOR security hole; you should delete it
} 	from your system as fast as possible.  I can't tell you what the hole
} 	is, because it would allow any hacker to break into any Unix system in
} 	the world.  Believe me; I know what I'm talking about.
} It's easy enough to make up warnings like these, but many of them turn out
} on investigation to be full of bull; some are in fact fraudulent attempts
} to discredit someone else's useful software.

	Read the source code.  I was simply pointing out something you should
be aware of.  The fix, if you haven't figured it out for yourself yet, is to
simply force the path for pwd.  I was simply suggesting that AT&T fix it.

} Anyhow, what can one do with getcwd() or popen() within a setuid program
} (root or otherwise) that isn't a consequence of the search path?

	Nothing.  That's not the point.  How do you specify the PATH env
variable from within your C program?  Inquiring minds want to know...
the who point, I thought, of this bugs forum, was to bring bugs to the
attention of the people in charge of removing them.

}                                                                   If there
} is a real security hole here, I'd be very interested in reading about it.

	Well... how do _you_ do a mknod under sys5?  Is it a suid root program
on _your_ system, like everone elses, or do you always log in as root?  Do you
determine path via osmosis, or some method unbeknownst to us?  If not, it's
a problem.

	When all else fails, consult the source code.

| Terry Lambert           UUCP: ...!{ decvax, ihnp4 }...                      |
| @ Century Software       or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |

Incidentally, note that the 4.3BSD /bin/sh does not import IFS from
the environment (like Doug Gwyn's BRL sh), except that it does this
*only* if you are root or if geteuid()!=getuid().  (Making it an exception
for root/setuid is, I think, bogus.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

In article <725@rivm05.UUCP> ccement@rivm.UUCP (Martien F v Steenbergen) writes:
>In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
>> In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
>> > be suspicious of any setuid program.
>> 
>> Uh, I'm not sure I believe all this.  I mean, I understand ...
* Believe it this is real. *
>
>enough. Perhaps there exists a book which describes a lot of Unix security
>related topics. I'd love to have one.

You are in luck.  I have a good one in front of me.
From Hayden Books Unix(R) System Library:

	UNIX (TM) System Security
	by Patrick H. Wood and Stephen G. Kochan
	Hayden Books, Indianapolis, Indiana,  46268, USA
	ISBN: 0-8104-6267-2  (my copy was $34.95)

Yes it covers a permutation of the same trap that has been making
this news group hummmm.

Thomas P. Mitchell (mitch@stride1.Stride.COM)
Phone: (702)322-6868	TWX: 910-395-6073	FAX: (702)322-7975
MicroSage Computer Systems Inc. a Division of Stride Micro.
Opinions expressed are probably mine. 

As quoted from <478@minya.UUCP> by jc@minya.UUCP (John Chambers):
+---------------
| In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
| > Second, when you really need a setuid program you'll have to check a lot
| > of permissions etc. yourself. 
| 
| This adds to my conviction that someone doesn't know what they're talking
| about.  Do you perhaps mean "setuid-root"?  If so, you are of course correct.
| If you don't understand my point, you don't know enough about Unix security
| to pontificate on the subject.
+---------------

If I wasn't *real* careful with the (setuid) program which grabs incoming
sources.misc submissions, someone could gain write access to any of my files.
Such as my .login.  This isn't a potential security hole?  (The alternative
is to make a certain directory world-writeable; not a sound idea in this case.)
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery

>	Nothing.  That's not the point.  How do you specify the PATH env
>variable from within your C program?  Inquiring minds want to know...
>the who point, I thought, of this bugs forum, was to bring bugs to the
>attention of the people in charge of removing them.

On Sys V or at least the one's I work on have a function called putenv(3)
and there is a public domain set of routines that will work on both
BSD and Sys V, called setenv(3l), delenv(3l), etc.

Cheers,



-- 
Darryl Wagoner		dpw@unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (512)-255-8751 (home) (512)-823-3774
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!dpw

In article <319@wsccs.UUCP> terry@wsccs.UUCP (terry) writes:
>In article <478@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
>} In article <722@rivm05.UUCP>, ccement@rivm.UUCP (Martien F v Steenbergen) writes:
>} In article <181@wsccs.UUCP>, I write:
>} > 	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.
>	Read the source code.  I was simply pointing out something you should
>be aware of.  The fix, if you haven't figured it out for yourself yet, is to
>simply force the path for pwd.  I was simply suggesting that AT&T fix it.

Enough, already.  Here's an alternative solution:

/*
	getcwd -- get current working directory name (POSIX and SVID compatible)

	last edit:	21-Sep-1987	D A Gwyn

	This public-domain getcwd() routine can be used to replace the UNIX
	System V library routine (which uses popen() to capture the output of
	the "pwd" command).  Once that is done, "pwd" can be reimplemented as
	just puts(getcwd()).

	This implementation depends on every directory having entries for
	"." and "..".  It also depends on the internals of the <dirent.h>
	data structures to some degree.

	I considered using chdir() to ascend the hierarchy, followed by a
	final chdir() to the path being returned by getcwd() to restore the
	location, but decided that error recovery was too difficult that way.
	The algorithm I settled on was inspired by my rewrite of the "pwd"
	utility, combined with the dotdots[] array trick from the SVR2 shell.
*/

#include	<sys/types.h>
#include	<sys/stat.h>
#include	<dirent.h>
#include	<errno.h>
#include	<string.h>

typedef char	*pointer;		/* (void *) if you have it */

extern void	free();
extern pointer	malloc();
extern int	fstat(), stat();

extern int	errno;			/* normally done by <errno.h> */

#ifndef NULL
#define	NULL	0			/* amorphous null pointer constant */
#endif

#ifndef NAME_MAX
#define	NAME_MAX	255		/* maximum directory entry size */
#endif

char	*
getcwd( buf, size )			/* returns pointer to CWD pathname */
	char		*buf;		/* where to put name (NULL to malloc) */
	int		size;		/* size of buf[] or malloc()ed memory */
	{
	static char	dotdots[] =
"../../../../../../../../../../../../../../../../../../../../../../../../../..";
	char 		*dotdot;	/* -> dotdots[.], right to left */
	DIR		*dirp;		/* -> parent directory stream */
	struct dirent	*dir;		/* -> directory entry */
	struct stat	stat1, stat2;	/* info from stat() */
	struct stat	*d = &stat1;	/* -> info about "." */
	struct stat	*dd = &stat2;	/* -> info about ".." */
	register char	*buffer;	/* local copy of buf, or malloc()ed */
	char		*bufend;	/* -> buffer[size] */
	register char	*endp;		/* -> end of reversed string */
	register char	*dname;		/* entry name ("" for root) */
	int		serrno = errno;	/* save entry errno */

	if ( size == 0 )
		{
		errno = EINVAL;		/* invalid argument */
		return NULL;
		}

	if ( (buffer = buf) == NULL	/* wants us to malloc() the string */
	  && (buffer = (char *)malloc( (unsigned)size )) == NULL
	   )	{
		errno = ENOMEM;		/* cannot malloc() specified size */
		return NULL;
		}

	if ( stat( ".", dd ) != 0 )	/* prime the pump */
		goto error;		/* errno already set */

	endp = buffer;			/* initially, empty string */
	bufend = &buffer[size];

	for ( dotdot = &dotdots[sizeof(dotdots)]; dotdot != dotdots; )
		{
		dotdot -= 3;		/* include one more "/.." section */
					/* (first time is actually "..") */

		/* swap stat() info buffers */
		{
		register struct stat	*temp = d;

		d = dd;			/* new current dir is old parent dir */
		dd = temp;
		}

		if ( (dirp = opendir( dotdot )) == NULL )	/* new parent */
			goto error;	/* errno already set */

		if ( fstat( dirp->dd_fd, dd ) != 0 )
			{
			serrno = errno;	/* set by fstat() */
			(void)closedir( dirp );
			errno = serrno;	/* in case closedir() clobbered it */
			goto error;
			}

		if ( d->st_dev == dd->st_dev )
			{		/* not crossing a mount point */
			if ( d->st_ino == dd->st_ino )
				{	/* root directory */
				dname = "";
				goto append;
				}

			do
				if ( (dir = readdir( dirp )) == NULL )
					{
					(void)closedir( dirp );
					errno = ENOENT;	/* missing entry */
					goto error;
					}
			while ( dir->d_ino != d->st_ino );
			}
		else	{		/* crossing a mount point */
			struct stat	t;	/* info re. test entry */
			char		name[sizeof(dotdots) + 1 + NAME_MAX];

			(void)strcpy( name, dotdot );
			dname = &name[strlen( name )];
			*dname++ = '/';

			do	{
				if ( (dir = readdir( dirp )) == NULL )
					{
					(void)closedir( dirp );
					errno = ENOENT;	/* missing entry */
					goto error;
					}

				(void)strcpy( dname, dir->d_name );
				/* must fit if NAME_MAX is not a lie */
				}
			while ( stat( name, &t ) != 0
			     || t.st_ino != d->st_ino
			     || t.st_dev != d->st_dev
			      );
			}

		dname = dir->d_name;

		/* append "/" and reversed dname string onto buffer */
    append:
		if ( endp != buffer	/* avoid trailing / in final name */
		  || dname[0] == '\0'	/* but allow "/" when CWD is root */
		   )
			*endp++ = '/';

		{
		register char	*app;	/* traverses dname string */

		for ( app = dname; *app != '\0'; ++app )
			;

		if ( app - dname >= bufend - endp )
			{
			(void)closedir( dirp );
			errno = ERANGE;	/* won't fit allotted space */
			goto error;
			}

		while ( app != dname )
			*endp++ = *--app;
		}

		(void)closedir( dirp );

		if ( dname[0] == '\0' )	/* reached root; wrap it up */
			{
			register char	*startp;	/* -> buffer[.] */

			*endp = '\0';	/* plant null terminator */

			/* straighten out reversed pathname string */
			for ( startp = buffer; --endp > startp; ++startp )
				{
				char	temp = *endp;

				*endp = *startp;
				*startp = temp;
				}

			errno = serrno;	/* restore entry errno */
			return buffer;
			}
		}

	errno = ENOMEM;			/* actually, algorithm failure */

    error:
	if ( buf == NULL )
		free( (pointer)buffer );

	return NULL;
	}

In article <892@cosmo.UUCP> jum@cosmo.UUCP (Jens-Uwe Mager(sysop))
reveals the IFS trick.

Jens-Uwe, lots of system administrators with SVR2 (or less) will hate you
now, because their task of maintaining a decent computer operation will
be turned sour by some would-like-to-be hackers, who are worse than
the real ones.

There is no real work-around in SVR2 except removing the set-userid
bits or even the programs. Even if you cannot spare a seperate
machine for networking you will be surprised how many set-userid bits
or set-userid bit programs may be removed without hindering the
system operation. Think about it and try it. Somebody should make
a list of such programs and comment on what happens if the bits
are removed. Here a small start of this list:

	at      program may be removed in most installations
	crontab remove suid-bit and let system administrator do
		crontab installation
	cu      should remove suid-bit and wait for complaints
	login   remove suid-bit -> logout via login does not work (no problem)
	rmail
	mail
	mailx   depending on several settings, e.g. umask, following
		procedure may work (as in SVR3)

		introduce new group "mail"

		chgrp mail /bin/mail /usr/bin/mailx
		chmod 2555 /bin/mail /usr/bin/mailx
		chgrp mail /usr/mail
		chmod 775  /usr/mail
		chgrp mail /usr/mail/*
		chmod 775  /usr/mail/*

	su      try the IFS-tick. If it does work REMOVE su. Write
		your own su if necessary.
	/usr/lib/ex*
		remove suid-bit (see other security articles!)
	umount
	mount   remove suid bits and wait for complaints
	...
	...

Does somebody care to comment or add to the list??

The IFS problem is fixed in SVR3.

Every single program that is subject to the "IFS" trick can be
protected by written a wrapper that sets the environment properly,
then calls the real program.  If you put all these programs in
one common directory, then you can have one front-end which has
hardlinks all over the place, and a simple exec based on argv[0].
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

In article <175@pcsbst.UUCP>, jh@pcsbst.UUCP (Johannes Heuft) writes:
> In article <892@cosmo.UUCP> jum@cosmo.UUCP (Jens-Uwe Mager(sysop))
> reveals the IFS trick.
> 
> Jens-Uwe, lots of system administrators with SVR2 (or less) will hate you
> now, because their task of maintaining a decent computer operation will
> be turned sour by some would-like-to-be hackers, who are worse than
> the real ones.
> 
> There is no real work-around in SVR2 except removing the set-userid
> bits or even the programs.

Yes, there is a workaround; it is tedious but it works.  Write
a small front-end (say. lp.c) that does:

	/*--------------------- lp.c -----------------------*/
	#define	REAL_LP	/usr/bin/.lp

	main(argc, argv)
	int	argc;
	char	*argv[];
	{
		putenv("IFS= \t\n");
		putenv("SHELL=/bin/sh");
		putenv("PATH=/bin:/usr/bin");

		execv(REAL_LP, argv);
	}
	/*--------------------- lp.c -----------------------*/

(*) rename /usr/bin/lp to /usr/bin/.lp
(*) install the above lp fix to /usr/bin/lp
(*) remove setuid/setgid permissions from /usr/bin/.lp
(*) add the setuid/setgid permission + owner + group to /usr/bin/lp
(*) remove all read access from the now-setuid file

The old program is still susceptible to the IFS bug but it is
entirely harmless: the setuid front-end will fix it.  Disclaimer:
no warranty that this fixes all bugs, prevents all scam, or stops
all hunger in the world.  It works for me but there are always
smarter people out there.

Not all of the programs Johannes mentions are at risk, but in
any case, it has been my experience that making all setuid or
setgid programs unreadable by anybody will help quite a bit.
There is much to be learned by poking around object files, and
closing this door makes it much more difficult to see where
the holes are or might be.

---
Steve Friedl      V-Systems, Inc.        *Hi Mom*
friedl@vsi.com   {uunet,attmail,ihnp4}!vsi!friedl

-- 
Steve Friedl      V-Systems, Inc.        *Hi Mom*
friedl@vsi.com   {uunet,attmail,ihnp4}!vsi!friedl

In article <175@pcsbst.UUCP> jh@pcsbst.UUCP (Johannes Heuft) writes:
>In article <892@cosmo.UUCP> jum@cosmo.UUCP (Jens-Uwe Mager(sysop))
>reveals the IFS trick.
>Jens-Uwe, lots of system administrators with SVR2 (or less) will hate you

Oh, come on.  The IFS trick is quite well-known, ESPECIALLY among
the "hackers" who like to mess up system operation.  It is better
for everyone to be aware of the problem than to pretend that by
not talking about it there will be no problem.

>There is no real work-around in SVR2 except ...
>The IFS problem is fixed in SVR3.

It is easy to fix this in the SVR2 shell, too:
/*	@(#)main.c	1.7	*/
...
	/*
	 * default internal field separators - $IFS
	 */
	assign(&ifsnod, sptbnl);	/* DAG -- was dfault(); now forced */

And don't say "but what if you don't have source"?  The originator
of your binary distribution DOES have source; get them to fix it.

In article <544@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
>Every single program that is subject to the "IFS" trick can be
>protected by written a wrapper that sets the environment properly,
>then calls the real program.

I tried to replace "/bin/sh" this way, and although everything seemed to
work great, eventually I found out that all my outbound news was being
rejected with a "inews: inbound news is garbled" on the remote machines.

Didn't have the time to track down the problem, so my system is insequre
again. Any suggestions?

#---------------- sh.c ----------------
main (argc, argv)
int argc;
char *argv[];
{
	putenv ("IFS=\" \t\n\"");
	execv ("/bin/SH", argv);
	return -1;
}
#---------------- ----------------


-- 
Johan Vromans                              | jv@mh.nl via European backbone
Multihouse N.V., Gouda, the Netherlands    | uucp: ..{uunet!}mcvax!mh.nl!jv
"It is better to light a candle than to curse the darkness"

In article <7521@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes:
> If I wasn't *real* careful with the (setuid) program which grabs incoming
> sources.misc submissions, someone could gain write access to any of my files.
> Such as my .login.  This isn't a potential security hole?  (The alternative
> is to make a certain directory world-writeable; not a sound idea in this case.)

OK, I'll bite.  Here are the permissions on my home directory and .login: 

drwxrwxr-x 21 jc       wheel        2560 Mar 24 08:30 .
-rw-r--r--  2 jc       wheel         250 Jan 29 14:53 .login

And here's the rnews command:

22531 -rwsr-sr-x 2 news news 114688 Mar 17 13:33 /news/bin/rnews   

Explain to me how someone could use this setuid-news, setgid-news program
to write into my .login file.  Now need to explain further; I do appreciate
why I wouldn't want you to do that.  But I don't quite see how this setup
makes it possible.

I do understand why I wouldn't want to turn off these setuid and setgid bits.
In my experience, rnews is very often triggered by things (like cron) that
are run by root, and I've seen a lot of problems caused by news files ending
up owned by root rather than news.  I wouldn't trust news run by root, and I
don't trust cron to correctly run things under other ids;  I've had too many
surprises there to believe that I can reliably control cron.  So the setuid
and setgid bits are needed to guarantee that cron can't start rnews up with
root permissions.  This seems to me to restrict incoming news to only those
directories with news write permissions.  If I'm wrong, I'd like to know, so
I can start looking for other ways to do the job.


-- 
[Send flames; they keep it cool in this lab :-]

Am I the same John Chambers as jc@minya?  You decide....
Hint:  That guy over at ut-sally is an imposter.  (;-)

In article <175@pcsbst.UUCP> jh@pcsbst.UUCP (Johannes Heuft) writes:
>In article <892@cosmo.UUCP> jum@cosmo.UUCP (Jens-Uwe Mager(sysop))
>reveals the IFS trick.
> ...
>Does somebody care to comment or add to the list??

The IFS stuff can be dealt with by patching the shell. Those with source
could easily add a putenv("IFS= \t\n") (or something equivalent) in some
convenient place to stop the shell from inheriting IFS.

If you don't have source, you could do what I did on a SVR2(-like) machine
I'm administrating. Write a small program that simply does:
		putenv("IFS= \t\n");
		execv("/bin/.real-sh", argv);
and call it /bin/sh. (you mv'd /bin/sh to /bin/.real-sh before of course!).
This works Ok on my machine. Does anybody know of any reasons why somehting
like this shouldn't be done?

>The IFS problem is fixed in SVR3.

How?
-- 
Mikael Pettersson           ! Internet:mpe@ida.liu.se
Dept of Comp & Info Science ! UUCP:    mpe@liuida.uucp  -or-
University of Linkoping     !          {mcvax,munnari,uunet}!enea!liuida!mpe
Sweden                      ! ARPA:    mpe%ida.liu.se@uunet.uu.net

In article <130@heart-of-gold>, jc@heart-of-gold (John M Chambers x7780 1E342) writes:
> I do understand why I wouldn't want to turn off these setuid and setgid bits.
> In my experience, rnews is very often triggered by things (like cron) that
> are run by root, and I've seen a lot of problems caused by news files ending
> up owned by root rather than news.  I wouldn't trust news run by root, and I
> don't trust cron to correctly run things under other ids;  I've had too many
> surprises there to believe that I can reliably control cron.  So the setuid
> and setgid bits are needed to guarantee that cron can't start rnews up with
> root permissions.  This seems to me to restrict incoming news to only those
> directories with news write permissions.  If I'm wrong, I'd like to know, so
> I can start looking for other ways to do the job.

Use su in your crontab:

	0 * * * * su news -c "rnews -U"

Then rnews (or whatever command you like) will run as news, not root.
Also wise to do this with anything else you really don't need root to
be running: like uucico.


-- 
Mike Clarkson						mike@ists.UUCP
Institute for Space and Terrestrial Science
York University, North York, Ontario,
CANADA M3J 1P3						(416) 736-5611

> Use su in your crontab:
> 
> 	0 * * * * su news -c "rnews -U"
> 
> Then rnews (or whatever command you like) will run as news, not root.

Or, if you're running an S5R2 or later "cron", just put this entry in "news"'s
"crontab" file rather than "root"'s.  (Make sure you allow "news" to run
"cron" by setting up "cron.allow" and "cron.deny" properly.)

In article <168@ists>, mike@ists (Mike Clarkson) writes:
> In article <130@heart-of-gold>, jc@heart-of-gold (John M Chambers x7780 1E342) writes:
> > ...  I wouldn't trust news run by root, and I
> > don't trust cron to correctly run things under other ids;  I've had too many
> > surprises there to believe that I can reliably control cron.
> 
> Use su in your crontab:
> 
> 	0 * * * * su news -c "rnews -U"

A reminder that 3B2/3B5 System V Release 2 and 3 have separate
crontabs for each user and they take care of doing the "su"
business for you.

-- 
Steve Friedl     V-Systems, Inc.     *Hi Mom*
friedl@vsi.com   {uunet,ihnp4}!vsi.com!friedl

In article <130@heart-of-gold> jc@heart-of-gold (John M Chambers x7780 1E342) writes:
.OK, I'll bite.  Here are the permissions on my home directory and .login: 
.
.drwxrwxr-x 21 jc       wheel        2560 Mar 24 08:30 .
.-rw-r--r--  2 jc       wheel         250 Jan 29 14:53 .login
.
.And here's the rnews command:
.
.22531 -rwsr-sr-x 2 news news 114688 Mar 17 13:33 /news/bin/rnews   
.
.Explain to me how someone could use this setuid-news, setgid-news program
.to write into my .login file.  Now need to explain further; I do appreciate
.why I wouldn't want you to do that.  But I don't quite see how this setup
.makes it possible.

It is not possible for someone to *directly* abuse this to write to your
(uid=jc, gid=wheel) .login file.  However, someone may be able to abuse
rnews and become uid=news, gid=news.  They would then have access to all of
news's files.  This is where the security break is.


BTW, some time ago I saw a file with the following permissions:

-rwsrwsrwx	foo	bar		somefile

From a security standpoint, what's wrong with this picture?? (Please DON'T
post answers to this question; it is merely rhetorical.)
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

In article <766@senilix.liu.se> mikpe@senilix.liu.se (Mikael Pettersson) writes:

>If you don't have source, you could do what I did on a SVR2(-like) machine
>I'm administrating. Write a small program that simply does:
>		putenv("IFS= \t\n");
>		execv("/bin/.real-sh", argv);
>and call it /bin/sh. (you mv'd /bin/sh to /bin/.real-sh before of course!).
>This works Ok on my machine. Does anybody know of any reasons why somehting
>like this shouldn't be done?

This doesn't fix the problem.  What stops me, Joe User, from doing an

$ exec /bin/.real-sh

and bypassing your /bin/sh program??


I was thinking that if you did a setuid/setgid on the new /bin/sh, this
might be able to fix the problem.  But the only solution that I have
thought of (so far) won't work.

What I thought of doing is changing the file attributes to the following:

---x--s--x	bin	sh		sh
---x--x---	bin	sh		.real-sh

but the problem is that Joe User (uid=foo, gid=bar) would be running
.real-sh as egid=sh, not as egid=bar.  The only way that I can think of
that would fix this problem would be to modify the source of .real-sh, but
then we wouldn't need the front end to the shell in the first place.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

In article <544@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
.Every single program that is subject to the "IFS" trick can be
.protected by written a wrapper that sets the environment properly,
.then calls the real program.

But what stops the user from bypassing the wrapper and calling the real
program directly?
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

In article <4212@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
} In article <544@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
} .Every single program that is subject to the "IFS" trick can be
} .protected by written a wrapper that sets the environment properly,
} .then calls the real program.
} 
} But what stops the user from bypassing the wrapper and calling the real
} program directly?

The wrapper is setuid and the "real" program has its special
permissions removed.  If you bypass the wrapper the best you
can do is break your own usercode :-).

-- 
Steve Friedl           V-Systems, Inc.            *Hi Mom*
friedl@vsi.com {uunet,ihnp4}!vsi.com!friedl attmail!friedl

In article <4212@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
.In article <544@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
..Every single program that is subject to the "IFS" trick can be
..protected by written a wrapper that sets the environment properly,
..then calls the real program.
.
.But what stops the user from bypassing the wrapper and calling the real
.program directly?

Simply, the problem is setuid bit programs that has a popen in them.

This does a exec of "sh -c program argvs".  This means that /bin/sh
is the problems with IFS.  So how can they bypass?

-- 
Darryl Wagoner		dpw@unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (512)-255-8751 (home) (512)-823-3774
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!dpw

In article <4210@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>In article <766@senilix.liu.se> mikpe@senilix.liu.se (Mikael Pettersson) writes:
>
>>[ I argued that renaming /bin/sh to /bin/.real-sh and having /bin/sh be a
>>  small C program that resets IFS before exec'ing /bin/.real-sh could be
>>  a reasonable way to close down the IFS hole for non-source systems. ]
>
>This doesn't fix the problem.  What stops me, Joe User, from doing an
>
>$ exec /bin/.real-sh
>
>and bypassing your /bin/sh program??

Nothing, but that's not the problem here. The problem is the use of popen()
in set-uid programs. Ok, here's the full story:

Suppose Joe User executes /bin/mail or some other possibly set-uid program
that might need to communicate with a trusted subprocess. This subprocess
is often created with a call like popen("<full-path>/foo") with /bin or /usr
in <full-path>. To do this, popen() forks off an instance of /bin/sh(*)
giving it "<full-path>/foo" as an argument. The intention is to have the
shell(*) interpret IO-redirections and whatever shell meta-syntax we wish to
use for us. Now, suppose the malicious user had reset IFS to "/" and exported
it. This means that the shell(*) will inherit IFS="/". Now, it's easy to see
what happens: the shell(*) will strip out the /-es from <full-path>, leaving
the argument looking like "usr bin foo" instead of "/usr/bin/foo". If there
is a program called "usr" in Joe User's PATH *IT* will be executed with the
uid intended for the trusted program, i.e., Joe User is root.

How do we prevent this? We can't change popen() to reset IFS and recompile
all sources with our new C-library since most systems don't have source
to begin with. My fix will, I believe, stop all attempts to use *this* hole
with minimal changes to the system. You don't even have to wait for your
vendor to do it for you since all it takes is a small (<10 lines) C-program.
(One problem might be that not all systems have putenv() in libc.a. In those
 cases one has to improvise, but it's still just another trivial 3-4 lines.)

>I was thinking that if you did a setuid/setgid on the new /bin/sh, this
>might be able to fix the problem.

I don't think so, since then the set-uid program doing the popen() would
create a child with wrong uid, like uid=sh instead of uid=root.


> _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
>' )  )				"The secret compartment of my ring I fill
> /  / _ , __o  ____		 with an Underdog super-energy pill."
>/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

-- 
Mikael Pettersson           ! Internet:mpe@ida.liu.se
Dept of Comp & Info Science ! UUCP:    mpe@liuida.uucp  -or-
University of Linkoping     !          {mcvax,munnari,uunet}!enea!liuida!mpe
Sweden                      ! ARPA:    mpe%ida.liu.se@uunet.uu.net

As quoted from <130@heart-of-gold> by jc@heart-of-gold (John M Chambers x7780 1E342):
+---------------
| In article <7521@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes:
| > If I wasn't *real* careful with the (setuid) program which grabs incoming
| > sources.misc submissions, someone could gain write access to any of my files.
| > Such as my .login.  This isn't a potential security hole?  (The alternative
| > is to make a certain directory world-writeable; not a sound idea in this case.)
| 
| OK, I'll bite.  Here are the permissions on my home directory and .login: 
| 
| drwxrwxr-x 21 jc       wheel        2560 Mar 24 08:30 .
| -rw-r--r--  2 jc       wheel         250 Jan 29 14:53 .login
| 
| And here's the rnews command:
| 
| 22531 -rwsr-sr-x 2 news news 114688 Mar 17 13:33 /news/bin/rnews   
| 
| Explain to me how someone could use this setuid-news, setgid-news program
| to write into my .login file.  Now need to explain further; I do appreciate
+---------------

-rwsr-xr-x   1 allbery  System     56462 Mar 20 16:33 /u/allbery/bin/stash

Recall that moderated submissions are *mailed* to the moderator, not posted.
And, of course, I should hope that I own my home directory and .login.
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery

>.
>.drwxrwxr-x 21 jc       wheel        2560 Mar 24 08:30 .
>.-rw-r--r--  2 jc       wheel         250 Jan 29 14:53 .login
>.
>.And here's the rnews command:
>.
>.22531 -rwsr-sr-x 2 news news 114688 Mar 17 13:33 /news/bin/rnews   
>.
>.Explain to me how someone could use this setuid-news, setgid-news program
>.to write into my .login file.  Now need to explain further; I do appreciate
>.why I wouldn't want you to do that.  But I don't quite see how this setup
>.makes it possible.
>
>It is not possible for someone to *directly* abuse this to write to your
>(uid=jc, gid=wheel) .login file.  However, someone may be able to abuse
>rnews and become uid=news, gid=news.  They would then have access to all of
>news's files.  This is where the security break is.

	Once a user has broken through the news uid and gid they can
	modify rnews. The hacker copies the genuine version to another
	place, then creates his own program which sets its effective
	user and group IDs back to the real user and group IDs. The
	program then creates a new file on another directory under your
	uid and gid with the mode 6777 (setuid, setgid, rwx for all).
	Later another program can be copied over it. Alternatively that
	program can be placed in the file by the bogus rnews.
	
	The new rnews then goes on to execute the real rnews, so the
	person who runs rnews will be completely unaware of what
	has happened.

	Voila... the hacker has your user and group IDs 
	and can modify your .login or anything else.

	BTW. I have broken through news programs with setuid
	and setgid on two occasions, which illustrates the
	fact that it is difficult to be certain about any
	setuid, setgid program.

	----------------------------------------------------------------
Internet: avenger@runx.ips.oz.au	Founder of the League of
UUCP: uunet!runx.ips.oz.au!avenger	Computer Criminals

In article <1458@runx.ips.oz> avenger@runx.ips.oz (Troy Rollo ) writes:
>The program then creates a new file on another directory under your
>uid and gid with the mode 6777 (setuid, setgid, rwx for all).
>Later another program can be copied over it. Alternatively that
>program can be placed in the file by the bogus rnews.

The "alternative" has to be used, since writing a file normally
clears the set-?ID bits, at least on reasonable implementations
of UNIX.  (The exception is when UID 0 does this, but "news"
should not be UID 0.)

In article <7659@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> The "alternative" has to be used, since writing a file normally
> clears the set-?ID bits, at least on reasonable implementations
> of UNIX.  (The exception is when UID 0 does this, but "news"
> should not be UID 0.)

SVR2 and SVR3 on the 3B2 don't clear set-?ID bits on write, and
I've not heard of any straight Sys V ports that do this.  No comment
on the "reasonable" tag, but I think that clear-set?id-on-write
is not as widespread as the above paragraph might indicate.  Too bad.
-- 
Steve Friedl   V-Systems, Inc.   "Yes, I'm jeff@unh's brother"
friedl@vsi.com  {backbones}!vsi.com!friedl  attmail!vsi!friedl