According to Geoff Hutchison:
> At 10:47 AM -0500 9/5/01, Gilles Detillieux wrote:
> >So, any ideas about how we can avoid abuses like the URL above, or that
> >described in bug #458013, but still allow -c from a wrapper script or
> >shell command line? Maybe we can ignore -c when REQUEST_METHOD is set
> >to GET or POST, and allow it otherwise?
>
> This is probably the best way. We can also check for one or more
> additional HTTP headers if we want to be sure. Certainly some
> behavior is already slightly different from the command-line than
> from the CGI. (e.g. the shell command will ask for "words" or
> "format" if they aren't supplied)
>
> >I suppose we could also have a compile time option to re-enable the old
> >behaviour for stubborn folks who'd rather put their systems at risk than
> >rewrite a wrapper. What do you think?
>
> That's not a bad idea--fairly easy to do as well.
Easy, perhaps, but I guess the question is do we really want to give
users enough rope to hang themselves with? If it's just a matter of
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.
> >I don't think the CONFIG_DIR environment variable is a problem, because
> >there's no way that I know of to arbitrarily define environment variables
> >for a CGI program from the web client.
>
> The web client isn't the only place the CGI needs to be secure. We
> also have to protect against shell access on the server grabbing the
> connection somehow. Again, I really think this needs to be closed--if
> someone wants to set a compile-time option to enable it, that's fine.
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.
I don't think it's a risk.
What do you mean by protecting against shell access on the server grabbing
the connection? How is a potential intruder going to get shell access on
the server, and what would CONFIG_DIR have to do with it? I don't see the
scenario here.
--
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
