Mailing List Archive

> Re Patch E66, which adds an IncludesYesCGInoCMD
> I don't think one should have to change ones config files to allow #include
> cgi scripts, as the security risk is low.
> I would rather Includes and IncludesNOEXEC allow #include of cgi scripts,
> and instead create a IncludesNOEXECCGI which disallowed both #cmd _and_
> #include of a cgi script. I don't think many people would need to use it,
> although they might use it out of paranoia.

it might be preferable syntactically, but it will probably
screw up lots of existing Options settings because IncludesNOEXEC
would suddenly have changed in meaning... that *would* be a security
headache.

> >screw up lots of existing Options settings because IncludesNOEXEC
> >would suddenly have changed in meaning... that *would* be a security
> >headache.
>
> Err, name one. 8-)

hmmm, that's a toughy. How about spoofing someone else's cgi-work ?,
and throw in some choice words of my own to wrap around theirs, maybe.
Spoof a cgi-script in such a way that it always crashes, telling the
owner about an error that just isn't there..

The infinite team of monekys with PCs are working on worse scenarios :-)

> My main point is that IncludesYesCGInoCMD is just too ugly a name for
> probably the most useful option.

Well that's another issue, one that is easily solved by a rename.

robh

>> Re Patch E66, which adds an IncludesYesCGInoCMD
>> ...I would rather Includes and IncludesNOEXEC allow #include of cgi
>> scripts, and instead create a IncludesNOEXECCGI which disallowed both #cmd
>> _and_ #include of a cgi script...
>> it, although they might use it out of paranoia.
>
>it might be preferable syntactically, but it will probably
>screw up lots of existing Options settings because IncludesNOEXEC
>would suddenly have changed in meaning... that *would* be a security
>headache.

Err, name one. 8-)

My main point is that IncludesYesCGInoCMD is just too ugly a name for
probably the most useful option.

David.

>
> > I have directories in which only a small subset of the well established
> > html files need includes. XBitHack lets me do that at the file level
> > granularity that I need.
> >
> > If XBITHACK were to be *replaced* by a directory config option, then
> > I'd be back to square one.
> > I've no objection to a per-directory based includes toggle switch, if it
> > didn't affect the existing XBITHACK system.
>
> How about this as a permanent solution to the problem, and a way to
> get rid of XBITHACK...
>
>
> The problem is that while I'd like to be able to define files as
> .shtml so that only they get parsed for includes, I already have
> lots of popular URLs ending in .html
>
> What if I rename by XBITHACK .html files to .shtml, and have Apache
> look for .shtml when it fails to find .html
>
> Includes are "expensive" anyway, so an extra stat for .shtml wouldn't
> amount to much.
>
> XBITHACK could then be confined to the bit bucket where it belongs.

This would definitely get my vote as it makes it much easier to
turn off Includes in user directories as I understand it.

> > > My main point is that IncludesYesCGInoCMD is just too ugly a name for
> > > probably the most useful option.
> > Well that's another issue, one that is easily solved by a rename.
> So have you got a better name? I suggest IncludesNoCmd.

sounds okay. If there are no objections, that could be fixed
when 0.6 is built. I think it's only mentioned once in httpd_config.c

> The other 'problem' I have with the patch is that it expands the options char
> to an int unnecessarily. You already have 2 bits for the includes status, and
> your extension increases the number of possibilities to 4.
> i.e. have OPT_INCLUDE_MASK (12) /* or something */
> OPT_INCLUDE_ALL (12) /* Includes, exec cgi and cmds */
> OPT_INCLUDE_NOCMD (8) /* #include of cgi scripts allowed */
> OPT_INCLUDE_NOEXEC (4) /* #include only, no cgi or cmd */
> OPT_INCLUDE_NONE (0) /* No include files */

I hadn't thought of using the bits that way, but I suspect we'll want
to expand the options again sooner or later. At least with an "int" we
have ample room to grow now.

>
> Actually, there's one per-directory config option which I've wanted to see
> for a while --- XBitHack. There's really no good reason why this, alone

I have directories in which only a small subset of the well established
html files need includes. XBitHack lets me do that at the file level
granularity that I need.

If XBITHACK were to be *replaced* by a directory config option, then
I'd be back to square one.
I've no objection to a per-directory based includes toggle switch, if it
didn't affect the existing XBITHACK system.

> I have directories in which only a small subset of the well established
> html files need includes. XBitHack lets me do that at the file level
> granularity that I need.
>
> If XBITHACK were to be *replaced* by a directory config option, then
> I'd be back to square one.
> I've no objection to a per-directory based includes toggle switch, if it
> didn't affect the existing XBITHACK system.

How about this as a permanent solution to the problem, and a way to
get rid of XBITHACK...


The problem is that while I'd like to be able to define files as
.shtml so that only they get parsed for includes, I already have
lots of popular URLs ending in .html

What if I rename by XBITHACK .html files to .shtml, and have Apache
look for .shtml when it fails to find .html

Includes are "expensive" anyway, so an extra stat for .shtml wouldn't
amount to much.

XBITHACK could then be confined to the bit bucket where it belongs.


robh

Actually, there's one per-directory config option which I've wanted to see
for a while --- XBitHack. There's really no good reason why this, alone
among includes-related behavior, should be configured at compile time, and
it does make it harder to test. There's actually a lot of server behavior
which should ideally be configurable per-directory --- an "int" gives us
room for this.

rst

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Fri, 14 Apr 95 10:14:56 MDT
>
> Actually, there's one per-directory config option which I've wanted to see
> for a while --- XBitHack. There's really no good reason why this, alone

I have directories in which only a small subset of the well established
html files need includes. XBitHack lets me do that at the file level
granularity that I need.

No, the proposal is to allow you to select the XBitHack or
non-XBitHack behavior on a per-directory basis, via Options in a
.htaccess file, if you choose to. If not, then sticking it once in
the Options declaration in http_access.c will get you XBitHack across
the whole server, exactly as you have now.

rst

> > My main point is that IncludesYesCGInoCMD is just too ugly a name for
> > probably the most useful option.
> Well that's another issue, one that is easily solved by a rename.
So have you got a better name? I suggest IncludesNoCmd.

The other 'problem' I have with the patch is that it expands the options char
to an int unnecessarily. You already have 2 bits for the includes status, and
your extension increases the number of possibilities to 4.
i.e. have OPT_INCLUDE_MASK (12) /* or something */
OPT_INCLUDE_ALL (12) /* Includes, exec cgi and cmds */
OPT_INCLUDE_NOCMD (8) /* #include of cgi scripts allowed */
OPT_INCLUDE_NOEXEC (4) /* #include only, no cgi or cmd */
OPT_INCLUDE_NONE (0) /* No include files */

David.

David wrote:

> Re Patch E66, which adds an IncludesYesCGInoCMD
> I don't think one should have to change ones config files to allow #include
> cgi scripts, as the security risk is low.
> I would rather Includes and IncludesNOEXEC allow #include of cgi scripts,
> and instead create a IncludesNOEXECCGI which disallowed both #cmd _and_
> #include of a cgi script. I don't think many people would need to use it,
> although they might use it out of paranoia.

My opinion is that I shouldn't have to add an IncludesNOEXECCGI (or whatever)
just to make my existing status (w/1.3R) regarding security and unnecessary
server load the same under Apache. I do use NOEXEC to prevent users from
including CGI stuff -- I don't trust my users and I don't trust CGI scripts
(even after I have checked them).

It would make more sense to keep IncludesNoExec as is and add

IncludesNoExecCMD

which just turns off exec cmd.

......Roy

On Sat, 15 Apr 1995, Roy T. Fielding wrote:
> My opinion is that I shouldn't have to add an IncludesNOEXECCGI (or whatever)
> just to make my existing status (w/1.3R) regarding security and unnecessary
> server load the same under Apache. I do use NOEXEC to prevent users from
> including CGI stuff -- I don't trust my users and I don't trust CGI scripts
> (even after I have checked them).

But... is there a big difference between
<!--#include virtual="/cgi-bin/nukeserver.pl" --> and
<a href="/cgi-bin/nukeserver.pl">Click here for nudie gifs!</a>?
I.e., if don't trust your users to create CGI scripts, you're not going
to give them the chance to #include one of theirs anyways.

> It would make more sense to keep IncludesNoExec as is and add
>
> IncludesNoExecCMD
>
> which just turns off exec cmd.

I'm just trying to keep featuritis and server bloat under control. Of
course if everyone wants to make this the Emacs of servers (lisp
interpreter, anyone? :) then I guess I'm outvoted.

Roy, if you come back and say it's truely not the same, then I'll relent.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Brian asked:

> But... is there a big difference between
> <!--#include virtual="/cgi-bin/nukeserver.pl" --> and
> <a href="/cgi-bin/nukeserver.pl">Click here for nudie gifs!</a>?
> I.e., if don't trust your users to create CGI scripts, you're not going
> to give them the chance to #include one of theirs anyways.

Yes -- CGI scripts are usually intended to be used in a certain way
and with a certain purpose in mind, and that is how I test them when
people ask me to put one in the scripts directory. Furthermore, I give
them a reasonably distinctive name so that a person selecting a hypertext
link can see that they are about to access a script (assuming they actually
care about these things).

In contrast, an #include cgi="" is activated without the user's knowledge
and within a different context (perhaps) than what was intended by the
script author.

As security concerns go, this ones pretty marginal. However, it is
significant enough for me to pro-actively avoid the maintenance hassles
of having to care about it. As it stands now, I don't even have the time
to check people's normal CGI scripts, so I just disallow them altogether
until the department pulls together the funds for a real webmaster.

.......Roy

On Mon, 17 Apr 1995, Roy T. Fielding wrote:
> As security concerns go, this ones pretty marginal. However, it is
> significant enough for me to pro-actively avoid the maintenance hassles
> of having to care about it. As it stands now, I don't even have the time
> to check people's normal CGI scripts, so I just disallow them altogether
> until the department pulls together the funds for a real webmaster.

Okay. Out of respect to Roy, who probably represents the needs of a
large body of webmasters out there of sites with large untrusted user
bases, and out of the realization that SSI's are fuct anyways, I rescind
my veto of any patch that has IncludesYesCGINoCMD (though I'd rather see
it named IncludesNoCMD), and I rescind my suggestion for making #include
allow the output of CGI scripts.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/