Mailing List Archive

includes security hole
Is there a way to block server side includes running "cmd", and
only allowing "cgi" ?

I bet lots of sites have restricted cgi directories but allow any
command to be executed via a "cmd" include.

If there's no way to block "cmd" while allowing "cgi", then Apache
should be fixed.

With so many sites allowing people to submit html (e.g. hyperreal and
our mailing list), there's a potential security hole here, just waiting
to be exploited.

robh
Re: includes security hole [ In reply to ]
On Mon, 10 Apr 1995, Robert S. Thau wrote:
> Is there a way to block server side includes running "cmd", and
> only allowing "cgi" ?
>
> I believe IncludesNoExec blocks both.

But he wants the granularity of blocking one and allowing the other. I
can see his point, though I'm tempted to suggest we backburner it for now.

> I bet lots of sites have restricted cgi directories but allow any
> command to be executed via a "cmd" include.
>
> If there's no way to block "cmd" while allowing "cgi", then Apache
> should be fixed.
>
> With so many sites allowing people to submit html (e.g. hyperreal and
> our mailing list), there's a potential security hole here, just waiting
> to be exploited.
>
> Only if includes are processed in the submitted HTML... even with
> XBITHACK on, I think that whatever is managing the HTMLified
> discussion forum would have to arrange for this specifically, either
> by writing into .shtml files, or by setting the xbit.

Right - when it's HTML that's being sucked up by a CGI script for
formatting, httpd won't be able to parse it for server-side includes
anyways. FTP uploaders also can't set the X bit, so places (like
hyperreal) set with that should be safe.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: includes security hole [ In reply to ]
From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Mon, 10 Apr 95 15:01:03 MDT

Is there a way to block server side includes running "cmd", and
only allowing "cgi" ?

I believe IncludesNoExec blocks both.

I bet lots of sites have restricted cgi directories but allow any
command to be executed via a "cmd" include.

If there's no way to block "cmd" while allowing "cgi", then Apache
should be fixed.

With so many sites allowing people to submit html (e.g. hyperreal and
our mailing list), there's a potential security hole here, just waiting
to be exploited.

Only if includes are processed in the submitted HTML... even with
XBITHACK on, I think that whatever is managing the HTMLified
discussion forum would have to arrange for this specifically, either
by writing into .shtml files, or by setting the xbit.

rst
Re: includes security hole [ In reply to ]
>
> >Is there a way to block server side includes running "cmd", and
> >only allowing "cgi" ?
>
> I've already thought about this, and was going to suggest the following:
> that #include be able to execute cgi scripts. I don't see any obvious
> security problems with this, even if cmd is blocked.

I had this working last night. I'll upload a patch sometime
today.

robh
Re: includes security hole [ In reply to ]
> The best thing might be to have yet another new allow option --- but
> unfortunately, with MultiViews, we've already got eight, which uses up
> just about all of the bits in a byte.

I extended the allows from a "char" to an "int" and
added IncludesYesCGInoCMD as an "Options" option.

We now have 32 bits to play with instead of 8.

patch later.
Re: includes security hole [ In reply to ]
>
> Hmmm... so "char opts[MAX_STRING_LEN]" in evaluate_access turns into
> an array of MAX_STRING_LEN int's... that's 32K on the stack. Not
> prohibitive, I suppose, but multiplied by every server in a pool it
> starts to add up. MAX_STRING_LEN is a bit high for the maximum
> number of directories in a pathname; perhaps it might be good to
> crank it down a bit.

Yup good idea. How about httpd.h MAX_SUB_DIRS 30

?
Re: includes security hole [ In reply to ]
/*
* "Re: includes security hole" by rst@ai.mit.edu (Robert S. Thau)
* written Tue, 11 Apr 95 10:48:24 EDT
*
* (Rob M. --- when you added IncludesNoExec to the code in the first
* place, did the people who requested it see CGI scripts as any
* particular concern?)
*
*/

Well, at the time I redesigned includes, the only commands were <INC
SRV "file"> and <INC SRV "|command">. You couldn't do CGI at all.

After NoExec was added I never really heard about it one way or the
other.

--Rob
Re: includes security hole [ In reply to ]
I try to stay out of server-side-include wars personally, since we don't
use the feature here much, and don't have much useful experience to go on.
However, allowing scripts to be invoked even with IncludesNoExec might
trigger flames from at least some of the knee-jerk safety-at-all-costs
types that I see on comp.security.unix from time to time.

It's not that I can see any particular security problems here --- frankly,
I can't, barring *very* contrived situations. However, there may be
people out there who feel differently.

The best thing might be to have yet another new allow option --- but
unfortunately, with MultiViews, we've already got eight, which uses up
just about all of the bits in a byte.

(Rob M. --- when you added IncludesNoExec to the code in the first place,
did the people who requested it see CGI scripts as any particular concern?)

rst
Re: includes security hole [ In reply to ]
>Is there a way to block server side includes running "cmd", and
>only allowing "cgi" ?

I've already thought about this, and was going to suggest the following:
that #include be able to execute cgi scripts. I don't see any obvious
security problems with this, even if cmd is blocked.

David.
Re: includes security hole [ In reply to ]
Hmmm... so "char opts[MAX_STRING_LEN]" in evaluate_access turns into
an array of MAX_STRING_LEN int's... that's 32K on the stack. Not
prohibitive, I suppose, but multiplied by every server in a pool it
starts to add up. MAX_STRING_LEN is a bit high for the maximum
number of directories in a pathname; perhaps it might be good to
crank it down a bit.

Just thinking out loud...

rst
Re: includes security hole [ In reply to ]
Yup good idea. How about httpd.h MAX_SUB_DIRS 30

I'd prefer making it an even hundred --- that's *completely* unreasonable.
30 is just on the bare threshold of plausibility...

rst
Re: includes security hole [ In reply to ]
> The other change I wanted to make to #include (and #exec cgi, I suppose) was
> to allow relative virtual paths to the included document, i.e.
> <--#include virtual="../inc.html" -->

I thought I was already doing that. I might be mistaken, I just
can't see the source of an example at the mo'.
Re: includes security hole [ In reply to ]
> Yup good idea. How about httpd.h MAX_SUB_DIRS 30
>I'd prefer making it an even hundred --- that's *completely* unreasonable.
>30 is just on the bare threshold of plausibility...

From solaris 2.4 limits.h:
#define PATH_MAX 1024 /* max # of characters in a path name */

So the maximum number of directories in a valid filename is 512.

We should probably reduce some of the HUGE_STRING_LEN variables to PATH_MAX
as well.

David.
Re: includes security hole [ In reply to ]
>I had this working last night. I'll upload a patch sometime
>today.
The other change I wanted to make to #include (and #exec cgi, I suppose) was
to allow relative virtual paths to the included document, i.e.
<--#include virtual="../inc.html" -->
Unfortuantely, this requires the URL of the current document to be known,
whereas httpd seems to have forgotten... Also, it would require parsing the
document for a <base> tag. Not difficult.

David.
Re: includes security hole [ In reply to ]
Date: Tue, 11 Apr 95 18:58 BST
From: drtr@ast.cam.ac.uk (David Robinson)

>I had this working last night. I'll upload a patch sometime
>today.
The other change I wanted to make to #include (and #exec cgi, I suppose) was
to allow relative virtual paths to the included document, i.e.
<--#include virtual="../inc.html" -->
Unfortuantely, this requires the URL of the current document to be known,
whereas httpd seems to have forgotten... Also, it would require parsing the
document for a <base> tag. Not difficult.

David.

The content negotiation code has a function which may be useful for
this, in part or in whole (substitute_mapped_name in http_mime_db.c,
which tries to interpret a URL relative to a given base; this is used
to resolve the URIs in map files).

rst