You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Temme <sc...@covalent.net> on 2002/05/03 23:30:29 UTC
[Patch] Concept: have MPM identify itself in Server header
All,
The following patch, inline and attached because of possible line-wrapping,
has the prefork MPM announce itself in the Server: header of all responses.
Having the MPM identify itself would provide insight in who is using Apache
in which configuration. It would allow groups like netstat to provide
statistics on MPM usage. The patch changes the Server string of the server
to "Server: Apache/2.0.37-dev (Unix) Prefork MPM".
I considered adding the ap_add_version_component to the prefork_pre_config
function rather than register another hook, but that would put the MPM
string before the base server component which may interfere with statics
gathering parsers. For the same reason, I didn't put it inside the base
server string.
Finally, adding this on a per-MPM basis rather than centrally provides the
flexibility for MPMs to identify themselves in their own way or not at all.
For instance, on platforms that have only one MPM, like Win32, it wouldn't
make a lot of sense to do so. It also keeps core.c free from contamination
as it doesn't have to know about human-readable MPM names.
Any thoughts on this? Good/bad idea, good/bad place/way to put it?
S.
Index: server/mpm/prefork/prefork.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.262
diff -u -r1.262 prefork.c
--- server/mpm/prefork/prefork.c 8 Apr 2002 16:57:05 -0000
1.262
+++ server/mpm/prefork/prefork.c 3 May 2002 19:50:02 -0000
@@ -1244,6 +1244,13 @@
return OK;
}
+static int prefork_post_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t
*ptemp)
+{
+ ap_add_version_component(p, "Prefork MPM");
+
+ return OK;
+}
+
static void prefork_hooks(apr_pool_t *p)
{
/* The prefork open_logs phase must run before the core's, or stderr
@@ -1258,6 +1265,7 @@
ap_hook_open_logs(prefork_open_logs, NULL, aszSucc, APR_HOOK_MIDDLE);
ap_hook_pre_config(prefork_pre_config, NULL, NULL, APR_HOOK_MIDDLE);
+ ap_hook_post_config(prefork_post_config, NULL, NULL, APR_HOOK_MIDDLE);
}
static const char *set_daemons_to_start(cmd_parms *cmd, void *dummy, const
char *arg)
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105
PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Austin Gonyou <au...@coremetrics.com>.
Damn...that's a bonk on the head. It probably should do that huh?
On Fri, 2002-05-03 at 16:30, Sander Temme wrote:
> All,
>
> The following patch, inline and attached because of possible
> line-wrapping,
> has the prefork MPM announce itself in the Server: header of all
> responses.
>
> Having the MPM identify itself would provide insight in who is using
> Apache
> in which configuration. It would allow groups like netstat to provide
> statistics on MPM usage. The patch changes the Server string of the
> server
> to "Server: Apache/2.0.37-dev (Unix) Prefork MPM".
>
> I considered adding the ap_add_version_component to the
> prefork_pre_config
> function rather than register another hook, but that would put the MPM
> string before the base server component which may interfere with statics
> gathering parsers. For the same reason, I didn't put it inside the base
> server string.
>
> Finally, adding this on a per-MPM basis rather than centrally provides
> the
> flexibility for MPMs to identify themselves in their own way or not at
> all.
> For instance, on platforms that have only one MPM, like Win32, it
> wouldn't
> make a lot of sense to do so. It also keeps core.c free from
> contamination
> as it doesn't have to know about human-readable MPM names.
>
> Any thoughts on this? Good/bad idea, good/bad place/way to put it?
>
> S.
>
> Index: server/mpm/prefork/prefork.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/server/mpm/prefork/prefork.c,v
> retrieving revision 1.262
> diff -u -r1.262 prefork.c
> --- server/mpm/prefork/prefork.c 8 Apr 2002 16:57:05 -0000
> 1.262
> +++ server/mpm/prefork/prefork.c 3 May 2002 19:50:02 -0000
> @@ -1244,6 +1244,13 @@
> return OK;
> }
>
> +static int prefork_post_config(apr_pool_t *p, apr_pool_t *plog,
> apr_pool_t
> *ptemp)
> +{
> + ap_add_version_component(p, "Prefork MPM");
> +
> + return OK;
> +}
> +
> static void prefork_hooks(apr_pool_t *p)
> {
> /* The prefork open_logs phase must run before the core's, or
> stderr
> @@ -1258,6 +1265,7 @@
>
> ap_hook_open_logs(prefork_open_logs, NULL, aszSucc,
> APR_HOOK_MIDDLE);
> ap_hook_pre_config(prefork_pre_config, NULL, NULL,
> APR_HOOK_MIDDLE);
> + ap_hook_post_config(prefork_post_config, NULL, NULL,
> APR_HOOK_MIDDLE);
> }
>
> static const char *set_daemons_to_start(cmd_parms *cmd, void *dummy,
> const
> char *arg)
>
>
> --
> Covalent Technologies sctemme@covalent.net
> Engineering group Voice: (415) 536 5214
> 645 Howard St. Fax: (415) 536 5210
> San Francisco CA 94105
>
> PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
>
> =======================================================
> This email message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information. Any unauthorized
> review,
> use, disclosure or distribution is prohibited. If you are not the
> intended
> recipient, please contact the sender by reply email and destroy all
> copies
> of the original message
> =======================================================
>
>
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@coremetrics.com
"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:24 PM 5/3/2002, you wrote:
>On Fri, 3 May 2002, Rasmus Lerdorf wrote:
>
> > Ok, but where should this information go then? Apache has definitely
> > benefitted by having this information available. Some sort of
> > X-SERVER-INFO: header then?
>
>What I meant was I don't think the MPM should be announced to the client.
>What possible benefit could there be to doing that?
And I agree here with Cliff...
The Server String provides clients some very useful information in compensating
for discrepancies between HTTP implementations. I've never agreed that this
"exposure of potential expoits" has any impact; most crackers are just
pummeling
every useful vulnerability against as many random machines as possible.
Changing the ServerString doesn't provide any useful data, since all MPMs treat
the HTTP protocol the same (and outright MPM bugs can't really be adjusted
for).
Denial of service exploits, however, may depend on understanding the request
processing model. A denial of service against worker likely has little or no
impact against perchild, etc.
The only advantage is for tracking mpm adoption rates, and I don't think that's
a sufficient benefit to outweigh this disadvantage. If HTTP requests would
react differently under different MPMs, my opinion would be swayed.
-0 on this concept here.
Bill
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Austin Gonyou <au...@coremetrics.com>.
Sorry for chiming in after the weekend on this. Just to clarify my
statement earlier though, I didn't mean that this info should be
presented to the client, but rather made available, say in the
server-signature string or some such thing. I've not seen it in there.
It would be nice to be able to identify the type of MPM used, mainly
like in signature.
Not sure how *safe* it is in general though.
On Fri, 2002-05-03 at 17:24, Cliff Woolley wrote:
> On Fri, 3 May 2002, Rasmus Lerdorf wrote:
>
> > Ok, but where should this information go then? Apache has definitely
> > benefitted by having this information available. Some sort of
> > X-SERVER-INFO: header then?
>
> What I meant was I don't think the MPM should be announced to the
> client.
> What possible benefit could there be to doing that?
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@coremetrics.com
"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Sander Temme <sc...@covalent.net>.
> What I meant was I don't think the MPM should be announced to the client.
> What possible benefit could there be to doing that?
I mainly had in mind that the authors could track usage that way.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105
PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Bill Stoddard <bi...@wstoddard.com>.
-----
>
>
> Cliff Woolley wrote:
> > On Fri, 3 May 2002, Rasmus Lerdorf wrote:
> >
> >
> >>Ok, but as far as I am concerned something like PHP, mod_dav, mod_perl,
> >>etc. are also server implementation details that do not belong in this
> >>header. Unless I misunderstood Roy's message. I don't see much of a
> >>difference between announcing PHP there and an MPM.
> >
> >
> > Possibly. I guess I draw the line by saying that it's okay to announce
> > version numbers, but configuration parameters are out. I don't have so
> > much of a problem with third-party modules announcing themselves.
> > mod_ssl and OpenSSL I find questionable at this point, however. <shrug>
>
> On this note
> what do people think in making the 'default' install only show the major
> version (ie.. Apache 2.0) instead of showing everything?
+1
Bill
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Brian Pane <br...@cnet.com>.
Ian Holsman wrote:
>
>
> Cliff Woolley wrote:
>
>> On Fri, 3 May 2002, Rasmus Lerdorf wrote:
>>
>>
>>> Ok, but as far as I am concerned something like PHP, mod_dav, mod_perl,
>>> etc. are also server implementation details that do not belong in this
>>> header. Unless I misunderstood Roy's message. I don't see much of a
>>> difference between announcing PHP there and an MPM.
>>
>>
>>
>> Possibly. I guess I draw the line by saying that it's okay to announce
>> version numbers, but configuration parameters are out. I don't have so
>> much of a problem with third-party modules announcing themselves.
>> mod_ssl and OpenSSL I find questionable at this point, however. <shrug>
>
>
> On this note
> what do people think in making the 'default' install only show the
> major version (ie.. Apache 2.0) instead of showing everything?
+1
--Brian
RE: [Patch] Concept: have MPM identify itself in Server header
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:06 PM 5/3/2002, you wrote:
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > At 06:08 PM 5/3/2002, Ian Holsman wrote:
> > >
> > >On this note what do people think in making the 'default' install only
> show the
> > >major version (ie.. Apache 2.0) instead of showing everything?
> >
> > -0 here too... the problem is that a proxy engine, knowing of a specific
> > bug with Apache 2.0.41 and prior could compensate for that shortcoming.
> > Having no version information means the proxy or other client may be
> > unable to accommodate that discrepancy with the HTTP specification.
>
>How prevalent is that in reality? I mean we allow anybody to bring what
>we report down to just major version number, so we really can't expect
>proxy servers to use what we report to circumvent problems, can we?
Of course it won't catch them all. That's when you end up with proxy
failure errors. The point is that a proxy _could_ correct for a bad server
if it knew what to expect. Take certain flaws in IIS's implementation.
Recognized, they can be worked around. Unrecognized, the proxies
of the world will simply throw up. Big deal.
There's another aspect to this debate. It isn't impossible to come up with
heuristics that describe a given server (based on header presence, absence,
order of headers, capitalization, and even bug results.) This can be down
to the specific sub revision or service pack level, depending on how the
behavior has been altered. IMHO - it's fruitless to "mask" the identity
of the HTTP protocol software. Brute force attacks will still succeed
against vulnerable servers, no matter what their identity reveals.
However, there is _no_ discrepancy in MPM responses, except for very
subtle timing disparities. It's the same server. So I don't see how
identifying the HTTP server, but not disclosing the MPM would contract
each other. Denial of Service isn't a one-shot, it may take a sustained
effort. So an MPM's vulnerability could be disclosed for targeted,
explicit exploit.
Just my 2c (US).
Bill
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Joshua Slive <jo...@slive.ca>.
Ryan Bloom wrote:
>>From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
>>-0 here too... the problem is that a proxy engine, knowing of a
>
> specific
>
>>bug with
>>Apache 2.0.41 and prior could compensate for that shortcoming. Having
>
> no
>
>>version information means the proxy or other client may be unable to
>>accommodate
>>that discrepancy with the HTTP specification.
>
>
> How prevalent is that in reality? I mean we allow anybody to bring what
> we report down to just major version number, so we really can't expect
> proxy servers to use what we report to circumvent problems, can we?
>
I'm not a big fan of encouraging clients to use the Server header for
anything important. But I think having specific version information in
there does have a use: it allows people who know what they are doing to
diagnose problems much easier. If your client can't seem to talk to the
specific server using, for example, chunked input, it is very valuable
to know whether you are dealing with 2.0.18 or 2.0.36.
Joshua.
RE: [Patch] Concept: have MPM identify itself in Server header
Posted by Ryan Bloom <rb...@covalent.net>.
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
>
> At 06:08 PM 5/3/2002, Ian Holsman wrote:
>
> >Cliff Woolley wrote:
> >>On Fri, 3 May 2002, Rasmus Lerdorf wrote:
> >>
> >>Possibly. I guess I draw the line by saying that it's okay to
announce
> >>version numbers, but configuration parameters are out. I don't have
so
> >>much of a problem with third-party modules announcing themselves.
> >>mod_ssl and OpenSSL I find questionable at this point, however.
<shrug>
> >
> >On this note
> >what do people think in making the 'default' install only show the
major
> >version (ie.. Apache 2.0) instead of showing everything?
>
> -0 here too... the problem is that a proxy engine, knowing of a
specific
> bug with
> Apache 2.0.41 and prior could compensate for that shortcoming. Having
no
> version information means the proxy or other client may be unable to
> accommodate
> that discrepancy with the HTTP specification.
How prevalent is that in reality? I mean we allow anybody to bring what
we report down to just major version number, so we really can't expect
proxy servers to use what we report to circumvent problems, can we?
Ryan
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:08 PM 5/3/2002, Ian Holsman wrote:
>Cliff Woolley wrote:
>>On Fri, 3 May 2002, Rasmus Lerdorf wrote:
>>
>>Possibly. I guess I draw the line by saying that it's okay to announce
>>version numbers, but configuration parameters are out. I don't have so
>>much of a problem with third-party modules announcing themselves.
>>mod_ssl and OpenSSL I find questionable at this point, however. <shrug>
>
>On this note
>what do people think in making the 'default' install only show the major
>version (ie.. Apache 2.0) instead of showing everything?
-0 here too... the problem is that a proxy engine, knowing of a specific
bug with
Apache 2.0.41 and prior could compensate for that shortcoming. Having no
version information means the proxy or other client may be unable to
accommodate
that discrepancy with the HTTP specification.
Bill
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Ian Holsman <ia...@apache.org>.
Cliff Woolley wrote:
> On Fri, 3 May 2002, Rasmus Lerdorf wrote:
>
>
>>Ok, but as far as I am concerned something like PHP, mod_dav, mod_perl,
>>etc. are also server implementation details that do not belong in this
>>header. Unless I misunderstood Roy's message. I don't see much of a
>>difference between announcing PHP there and an MPM.
>
>
> Possibly. I guess I draw the line by saying that it's okay to announce
> version numbers, but configuration parameters are out. I don't have so
> much of a problem with third-party modules announcing themselves.
> mod_ssl and OpenSSL I find questionable at this point, however. <shrug>
On this note
what do people think in making the 'default' install only show the major
version (ie.. Apache 2.0) instead of showing everything?
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 3 May 2002, Rasmus Lerdorf wrote:
> Ok, but as far as I am concerned something like PHP, mod_dav, mod_perl,
> etc. are also server implementation details that do not belong in this
> header. Unless I misunderstood Roy's message. I don't see much of a
> difference between announcing PHP there and an MPM.
Possibly. I guess I draw the line by saying that it's okay to announce
version numbers, but configuration parameters are out. I don't have so
much of a problem with third-party modules announcing themselves.
mod_ssl and OpenSSL I find questionable at this point, however. <shrug>
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Rasmus Lerdorf <ra...@apache.org>.
Ok, but as far as I am concerned something like PHP, mod_dav, mod_perl,
etc. are also server implementation details that do not belong in this
header. Unless I misunderstood Roy's message. I don't see much of a
difference between announcing PHP there and an MPM.
-Rasmus
On Fri, 3 May 2002, Cliff Woolley wrote:
> On Fri, 3 May 2002, Rasmus Lerdorf wrote:
>
> > Ok, but where should this information go then? Apache has definitely
> > benefitted by having this information available. Some sort of
> > X-SERVER-INFO: header then?
>
> What I meant was I don't think the MPM should be announced to the client.
> What possible benefit could there be to doing that?
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 3 May 2002, Rasmus Lerdorf wrote:
> Ok, but where should this information go then? Apache has definitely
> benefitted by having this information available. Some sort of
> X-SERVER-INFO: header then?
What I meant was I don't think the MPM should be announced to the client.
What possible benefit could there be to doing that?
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Rasmus Lerdorf <ra...@apache.org>.
Ok, but where should this information go then? Apache has definitely
benefitted by having this information available. Some sort of
X-SERVER-INFO: header then?
-Rasmus
On Fri, 3 May 2002, Cliff Woolley wrote:
> On Fri, 3 May 2002, Roy T. Fielding wrote:
>
> > I do not believe that the Server string should be used to describe
> > implementation details of the server software. I know we already
> > do that, over my objections.
>
> FWIW, I agree with Roy on this one.
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 3 May 2002, Roy T. Fielding wrote:
> I do not believe that the Server string should be used to describe
> implementation details of the server software. I know we already
> do that, over my objections.
FWIW, I agree with Roy on this one.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by Sander Temme <sc...@covalent.net>.
> I do not believe that the Server string should be used to describe
> implementation details of the server software. I know we already
> do that, over my objections.
This can be manipulated using the ServerTokens directive; the patch I
submitted subjects itself to that setting.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105
PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================
Re: [Patch] Concept: have MPM identify itself in Server header
Posted by "Roy T. Fielding" <fi...@apache.org>.
I do not believe that the Server string should be used to describe
implementation details of the server software. I know we already
do that, over my objections.
....Roy