According to Geoff Hutchison:
> On Thu, 6 Sep 2001, Gilles Detillieux wrote:
> > getting users to rewrite a few wrapper scripts, I don't have a problem
> > with just yanking this rug out from under them. (Boy, am I mixing my
> > metaphors or what?) But if some other unforseen things will break by
> > removing -c capability from the htsearch CGI, it may be worth the risk
> > of having a compile-time option to revert to the old behaviour.
>
> Off the top of my head, I can't think of anything that would potentially
> break--given usual testing. Granted, that's the definition of
> "unforseen." :-)
>
> In some sense, the rug will be pulled out from many users even with a
> compile-time option. It clearly shouldn't be the default, and I
> doubt RPM maintainers will want to use the option. So anyone just running
> ./configure; make, or installing a binary will have to rewrite.
Good point. So, if it's not hard to put a compile-time option to have the
old behaviour revert, I don't have a problem with that. I guess it could
just be done with an #ifdef or #ifndef around the new test.
> > I really don't follow you on this point. If the CONFIG_DIR environment
> > variable is vulnerable in the htsearch CGI, then theoretically any
> > environment variable in any CGI is equally vulnerable, so there's no
> > CGI security at all. After all, you could override LD_LIBRARY_PATH,
> > or REQUEST_METHOD, or PATH and IFS. What I don't get is how a hostile
> > user could override any arbitrary environment variable in a CGI program.
>
> For this reason, actually, CGIs are supposed to set PATH
> themselves. <http://www.w3.org/Security/Faq/wwwsf4.html#CGI-Q8>
OK, so they talk about how a "favorite hacker's trick is to alter the
PATH environment variable", with no supporting documentation as to how
this is possible, if at all. If this is possible, will someone please
tell me how. And if so, how do we protect other vulnerable environment
variables like LD_LIBRARY_PATH? The way I see it, if you can hack a CGI
program's environment from a web client, then it's pretty near impossible
to write a safe CGI program.
> >From the "Safe CGI programming FAQ"
> ---
> DON'T MAKE ASSUMPTIONS ABOUT YOUR ENVIRONMENT:
> Just because cgi-bin programs are traditionally
> executed within the sanitized environment provided by the
> webserver, on multiuser systems it may be possible for other
> users to execute your cgi-bin programs, or force an execution
> of them in an unexpected context.
> ---
>
> Can I come up with all sorts of other nasty situations if a local user
> hijacks the CGI environment variables? Yes.
OK, now you're talking about something completely different, as is the
Safe CGI programming FAQ above. Protecting yourself from local users
is quite different than protecting yourself from web clients. So, if
a local user hacks CONFIG_DIR, so what? He can find a convoluted way
of reading a local file that he could directly view with cat, more,
less, vi, etc. I don't see a hole there.
On the other hand, if you're writing a set uid or set gid CGI program,
then you certainly need to take into account what a local user might
attempt to do. htsearch doesn't change uid or gid, so it's not a threat
in the hands of a local user. There's something to be said for checking
input anyway so the program doesn't dump core if the environment variables
aren't set just right, which is something I've fixed in htsearch already.
That's not a security issue, though.
> Do I see a good reason to keep
> the getenv("ONFIG_DIR")? No.
See http://www.htdig.org/FAQ.html#q4.20
> Again, it might be convenient, but I think it
> adds a potential (if convoluted) hole.
Certainly more convoluted than an exploit of -c, which itself is pretty
convoluted. Of course, the CONFIG_DIR env. variable adds just as much
convenience as -c. It's no harder to change the DEFAULT_CONFIG_FILE
makefile variable, recompile, link and install than it is to do so for
CONFIG_DIR.
So, why are we supposed to use tweezers to fix a known and fairly obvious
hole, and a sledgehammer to fix a more obscure one? If the environment
variables aren't safe, then the proposed check of REQUEST_METHOD to
block use of -c in a CGI isn't safe either. If we must do away with the
CONFIG_DIR environment variable because it's unsafe, we must also do away
with htsearch's -c option altogether (because there's no safe way to be
sure we're called from a shell wrapper and not directly as a CGI), and do
away with all shared libraries (even the standard C and C++ libraries)
for htsearch, because the LD_LIBRARY_PATH isn't safe, and cross our
fingers that some other environment variable won't bite us in the behind.
But if we're going to go to such extremes, I think we need something more
solid to base it on than a vague concern that the environment variables
might get hacked, i.e. a plausible scenario of how one might do just that.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev
