According to Geoff Hutchison:
> In any case, I'd like to get a patch (and perhaps 3.1.6) out relatively soon.
I see you put in the fix to safeguard against -c from a CGI. Thanks.
I too would like to see 3.1.6 out before too long. I'd really like to
get url_rewrite_rules in before we release, though. It was requested
so often in the past several months. It needs to be modified to use
regcomp() and regexec(), though, for portability and consistency.
One other thing that's a must, I think, is to add a new section to
the documentation on how to run ht://Dig. Thinking about a lot of
the questions we get on the list, and what we can't simply RTFM about
(because it's not there), I realised this was the big gap. Other than
a few passing references in the FAQ, there's nothing describing rundig.
We'd need something outlining the steps to follow after configuring.
I've started on a manual page for rundig, but I'd also like to have a
"Running ht://Dig" section to follow the sections on Installation and
Configuration.
I had a few other things on my wish list, but I don't think we
should hold up the 3.1.6 release for them. There are a few things in
3.1.6 that haven't gone into 3.2 yet either, namely boolean_keywords,
boolean_syntax_errors & multimatch_method, as well as the multi-excerpt
patch.
> At 3:36 PM -0500 9/6/01, Gilles Detillieux wrote:
> >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.
>
> No, no. It's a two-fold attack. With shell access you change the
> environment and then the CGI is remotely vulnerable. Granted, I'm not
> sure how you do the attack--I sent a message to bugtraq asking if
> there were pointers (and outlined this discussion in general about
> CGIs).
I'm not sure what shell access gets you in this regard. One of
the reasons we began recommending setting LD_RUN_PATH instead of
LD_LIBRARY_PATH for htsearch is because setting environment variables
for CGI programs is difficult, and requires access to the server
configuration. I don't see how an exploit that maninpulates the CGI
environment would be done without access privileges or some other serious
security hole.
> >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?
>
> I'm not clear on why removing code involves a tweezers in one hand
> and a sledgehammer in another.
Our fix for -c involves checking an environment variable, rather than
removing the -c option altogether. That's the tweezers. We opted for
a surgical approach to minimizing the threat posed by -c. On the other
hand, for CONFIG_DIR you're advocating knocking that code right out of
htsearch. That's the sledgehammer. This is inconsistent because in the
first case, our surgical fix is dependent on the same environment which,
in the second case, you argue is untrustworthy.
> >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.
>
> Look, it's a fine point. Personally, I'd much rather not have such
> explicit trust in an environment variable. Your points about
> LD_LIBRARY_PATH and so on are good, but I'll just say that if we
> leave CONFIG_DIR in there, I'm going to patch it on my copies. Call
> it paranoia if you like.
Well, call it what you like, but all I'm saying is we should be consistent
in closing supposed security holes. If we close one, but leave two or
three others just like it, we've accomplished nothing. If CONFIG_DIR
can't be trusted, can we be certain REQUEST_METHOD or other environment
variables can? If the environment variables are untrustworthy, we need
to protect htsearch against all of them.
--
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
