Re: configfile_t.param

[Lou Langholtz <ld...@eden.chpc.utah.edu>]

> BTW, your technique also fails on unixes which allow folks to "chown away"
> files.  For example, on IRIX you can "chown someoneelse .htaccess", and it
> will let you give away the file.
> 
> Also on any unix I can:
> 
>     mkdir public_html/teehee
>     cd public_html/teehee
>     ln -s ~victim/public_html/.htaccess
> 
> and your fstat() will return the userid of the victim.
> 
> Dean

Thanks. Good points.

Fortunately I can also use the behavior of the set
user id bit to get around chown'ing away the htacces file, and can lstat the
parms->config_file->name to disallow htaccess files that are symlinks.
Additionally I can check that the device and inode are the same between the
result from the fstat() and the lstat(). Have I missed anything?

Now how about we go back to discussing a standard way to get the htaccess
file descriptor :-) Also the, filename so long as I've brought it up. I'd
really like to avoid the case where the directives are read out of one
file and then security is tricked by lstat()'ing another file without
resorting to reparsing the htaccess file in my module. I can do that
I believe by checking that the inode and device numbers match between the
fstat() and the lstat() but only if I can get the descriptor for the fstat()

Just some extra details for anybody that got lost...

on the set user id bit behavior for anyone unfamiliar with
what we're talking about:

set user id bit is always cleared by the unix on any unix that allows
normal users to chown away files. otherwise you'd just be able to chown
your setusedid copy of /bin/sh to root and get a root shell.
so by checking if the file's set used id bit is on, one can be
assured that no one but root could have chown'd the file away,
thereby preventing chown victimization.

Re: configfile_t.param

[Lou Langholtz <ld...@chpc.utah.edu>]

Dean Gaudet wrote:

> On Mon, 1 Jun 1998, Lou Langholtz wrote:
>
> > > BTW, your technique also fails on unixes which allow folks to "chown away"
> > > files.  For example, on IRIX you can "chown someoneelse .htaccess", and it
> > > will let you give away the file.
> > >
> > > Also on any unix I can:
> > >
> > >     mkdir public_html/teehee
> > >     cd public_html/teehee
> > >     ln -s ~victim/public_html/.htaccess
> > >
> > > and your fstat() will return the userid of the victim.
> > >
> > > Dean
> >
> > Thanks. Good points.
> >
> > Fortunately I can also use the behavior of the set
> > user id bit to get around chown'ing away the htacces file, and can lstat the
> > parms->config_file->name to disallow htaccess files that are symlinks.
> > Additionally I can check that the device and inode are the same between the
> > result from the fstat() and the lstat(). Have I missed anything?
>
> hard links.

. . .

Dean, I've though about hard links and am afraid to tell you that I can't see how
they could work around all the checks I've mentioned so far. I'd imagine you've
had to consider this a lot more times than I though. But if I'm really missing
something on hard links, please explain how they could comprimise the checks.

Thanks.

Re: configfile_t.param

[Dean Gaudet <dg...@arctic.org>]

On Mon, 1 Jun 1998, Lou Langholtz wrote:

> > BTW, your technique also fails on unixes which allow folks to "chown away"
> > files.  For example, on IRIX you can "chown someoneelse .htaccess", and it
> > will let you give away the file.
> > 
> > Also on any unix I can:
> > 
> >     mkdir public_html/teehee
> >     cd public_html/teehee
> >     ln -s ~victim/public_html/.htaccess
> > 
> > and your fstat() will return the userid of the victim.
> > 
> > Dean
> 
> Thanks. Good points.
> 
> Fortunately I can also use the behavior of the set
> user id bit to get around chown'ing away the htacces file, and can lstat the
> parms->config_file->name to disallow htaccess files that are symlinks.
> Additionally I can check that the device and inode are the same between the
> result from the fstat() and the lstat(). Have I missed anything?

hard links.

> Now how about we go back to discussing a standard way to get the htaccess
> file descriptor :-) Also the, filename so long as I've brought it up. I'd
> really like to avoid the case where the directives are read out of one
> file and then security is tricked by lstat()'ing another file without
> resorting to reparsing the htaccess file in my module. I can do that
> I believe by checking that the inode and device numbers match between the
> fstat() and the lstat() but only if I can get the descriptor for the fstat()

As I've said already:  there may not be a file descriptor.  There may not
even be a filename, the name parameter is a descriptive text intended for
human consumption (in error messages).  The method you're using won't work
at all.  In fact it won't even compile in 1.3.0 because I made poolfile_t
a private type in util.c... it shouldn't have been public, it is a private
interface. 

I suspect that there's an entirely easier solution that isn't prone to
security problems.  If this is crud in ~user URLs then just use the
embedded user in the URL.  Otherwise it's probably crud under a
/blah/blah/docroot/user hierarchy (where user may be a domain name) and
you can compare against the uid of that file.  Without knowing a lot more
about your application I can't say. 

Dean