suexec: lstat vs stat

[David Harris <dh...@drh.net>]

Hi,

I'm working with src/support/suexec.c and I notice that all of the
permission checking at the end is done with lstat(2) call and not stat(2). I
wonder why because the mode from this stat is being used to check both the
directory's and the program's mode and ownership. Seems to me that you want
to check the file the link points to, not the link - i.e. use stat instead
of lstat.

Note that cwd should be symbolic link free, because it was returned from
getcwd(3). However, it would be bad practice to rely on this. And it is
fully possible that cmd may be a symbolic link.

Ok, where am I wrong with this?

 - David Harris
   Principal Engineer, DRH Internet Services


--- suexec.c.orig       Thu Mar 11 00:42:12 1999
+++ suexec.c    Thu Mar 11 00:42:46 1999
@@ -460,7 +460,7 @@
     /*
      * Stat the cwd and verify it is a directory, or error out.
      */
-    if (((lstat(cwd, &dir_info)) != 0) || !(S_ISDIR(dir_info.st_mode))) {
+    if (((stat(cwd, &dir_info)) != 0) || !(S_ISDIR(dir_info.st_mode))) {
        log_err("cannot stat directory: (%s)\n", cwd);
        exit(115);
     }
@@ -476,7 +476,7 @@
     /*
      * Error out if we cannot stat the program.
      */
-    if (((lstat(cmd, &prg_info)) != 0) || (S_ISLNK(prg_info.st_mode))) {
+    if (((stat(cmd, &prg_info)) != 0) || (S_ISLNK(prg_info.st_mode))) {
        log_err("cannot stat program: (%s)\n", cmd);
        exit(117);
     }

Re: suexec: lstat vs stat

["Jason A. Dour" <ja...@dour.org>]

On Thu, 11 Mar 1999, Ian Kallen wrote:
> I have'nt had need to use it except for some Truly Evil Experiments but it
> always seemed to me that the suexec dials and levers are pretty limited;
> maybe the runtime configuration for suexec should be more instrumented
> than merely checking for it in sbin/ -- the scenario below could be
> regulated as an Option with SymLinksIfOwnerMatch, right?  OTOH, why should
> people be rescued from themselves; if they want to share needles or
> skydive without a backup parachute or do other patently dump things and
> they're apprised of the risks then we can't really fret over their demise:
> it's their wittingly made choice.

Except that it could reflect negatively upon Apache in the long run.

Two decisions were made about suEXEC early on:

1.  It should not be a part of the default install since it could easily
    lead to security breaches in the hands of the less knowledgable.

2.  It should be as stringent as possible while still doing its job, since
    we didn't want to see a CERT advisory about Apache because of a
    non-default feature.

Sure...those are both a little selfish on the part of the Apache
Group...but I think they are justifiable decisions...

As far as the SymLinksIfOwnerMatch...IDK...suEXEC has to be EXTREMELY
paranoid about everything since we have no secure means of certifying
who/what is running the suEXEC binary.  We've chased our tails on how to
authenticate the server to the suEXEC binary, and there simply is no easy,
low-overhead method of authentication that we could find.

That was the stumbling block behind having suEXEC entend past VHosts and
UserDirs....


Jason
# "Jason A. Dour" <ja...@dour.org>       (http://dour.org/jason/)
# Finger for URLs, PGP Key, Geek Code, PJ Harvey info, et cetera.

Re: suexec: lstat vs stat

[Ian Kallen <ia...@gamespot.com>]

I have'nt had need to use it except for some Truly Evil Experiments but it
always seemed to me that the suexec dials and levers are pretty limited;
maybe the runtime configuration for suexec should be more instrumented
than merely checking for it in sbin/ -- the scenario below could be
regulated as an Option with SymLinksIfOwnerMatch, right?  OTOH, why should
people be rescued from themselves; if they want to share needles or
skydive without a backup parachute or do other patently dump things and
they're apprised of the risks then we can't really fret over their demise:
it's their wittingly made choice.

On Thu, 11 Mar 1999, Jason A. Dour wrote:
>Person A is not a programmer, but he wants some stuff for his webpage that
>require CGI.  Person B happens to have the necessary software -- one
>of their own design.  Person A makes a link to Person B's executable.
>Person A now is running foreign code as themself.  Person B decides they
>are mad at Person A, changes the code to do some nasty things (such as
>deleting perosnal files, sending harrassing emails to the head of the
>country, et cetera).  Person A, unaware of Person B's hatred, continues to
>use the new code, AS THEMSELVES (thanks to your version of suEXEC), and
>suddenly they are in a world of hurt.

--
Ian Kallen <ia...@gamespot.com>				ICQ: 17073910

Re: suexec: lstat vs stat

["Jason A. Dour" <ja...@dour.org>]

On Thu, 11 Mar 1999, David Harris wrote:
[Detail about suexec lstat versus stat deleted.]
> Ok, where am I wrong with this?

Hello David...

I'm one of the people who have mucked around with suEXEC from its early
stages (although I must admit to being WAY to busy to participate these
last six months or so)...  I think I can answer your question.

I'm not certain if the suEXEC documentation I wrote visited this issue,
but the decision to use lstat() versus stat() was one based on security.
If you will notice, later conditions in the if statement check to see if
the directory or the program IS A LINK.  If either are a link, it errors
out.  This is a consciously chosen method.  Why?  We want to make it DAMN
difficult for people using suEXEC to get burned.  Take this example into
account:

Person A is not a programmer, but he wants some stuff for his webpage that
require CGI.  Person B happens to have the necessary software -- one
of their own design.  Person A makes a link to Person B's executable.
Person A now is running foreign code as themself.  Person B decides they
are mad at Person A, changes the code to do some nasty things (such as
deleting perosnal files, sending harrassing emails to the head of the
country, et cetera).  Person A, unaware of Person B's hatred, continues to
use the new code, AS THEMSELVES (thanks to your version of suEXEC), and
suddenly they are in a world of hurt.

With lstat(), the above can't happen.  That's why we used it.  Does that 
answer your question?  8)



Jason
# "Jason A. Dour" <ja...@dour.org>       (http://dour.org/jason/)
# Finger for URLs, PGP Key, Geek Code, PJ Harvey info, et cetera.