You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2012/03/16 15:18:51 UTC
TRACE still enabled by default
We still enable TRACE by default.
Is this useful enough to justify making every other poor sap with a
security scanner have to manually turn it off?
I'm hoping 2.4.x is early enough in life where flipping this wouldn't
be too astonishing.
Re: TRACE still enabled by default
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 20 March 2012, Julian Reschke wrote:
> How so? When you say "webapps", are you referring to something not
> running via script/XHR?
Sorry, I meant to write "browser plugins" instead of webapps.
Re: TRACE still enabled by default
Posted by Tim Bannister <is...@jellybaby.net>.
On 21 Mar 2012, at 21:46, Stefan Fritsch wrote:
> But one thing that would be very interesting in this case, namely the X-Forwarded-For header, is something that most admins of a reverse-proxied site do NOT want to disclose at the end-point. They may also not want to reveal other headers sent from the reverse proxy to the end-point.
The same may apply to Via: … and in both cases the answer may be to disable or restrict the TRACE method.
But isn't this more a documentation issue than an argument for changing the compiled-in default?
--
Tim Bannister – isoma@jellybaby.net
Re: TRACE still enabled by default
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 21 March 2012, William A. Rowe Jr. wrote:
> On 3/21/2012 2:59 PM, Mark Montague wrote:
> > On March 21, 2012 15:33 , "Roy T. Fielding" <fi...@gbiv.com>
wrote:
> >> TRACE won't work at all if the most popular end-point doesn't
> >> support it.
> >
> > Why would this be a bad thing? Or, to phrase it another way,
> > what are the situations in which it is desirable that TRACE be
> > already-enabled on a web server as opposed to having the owner
> > of the web server enable the TRACE method in response to a
> > specific debugging need?
>
> Because, if you do NOT own the end-point, but are trying to debug a
> fault in a proxy which you DO own, then the lack of support in the
> upstream proxies or origin server leave you no ability to perform
> this diagnostic.
But one thing that would be very interesting in this case, namely the
X-Forwarded-For header, is something that most admins of a reverse-
proxied site do NOT want to disclose at the end-point. They may also
not want to reveal other headers sent from the reverse proxy to the
end-point.
> The output was never intended for unfiltered display. IIS provided
> for the TRACE results to be emitted to the browser with no
> consideration to cross-site scripting implications. There WAS a
> browser bug, but never an actual flaw with the protocol or Apache
> implementation.
That's beside the point. I completely agree that TRACE is not a flaw
in the protocol or server implementation. But it makes exploitation of
some other vulnerabilities easier, be it bugs in browsers, browser
plugins, request splitting bugs in proxies, or whatever. That's enough
reason not to enable it by default, IMNSHO.
> Most of the security reports and scanner output
> mischaracterizes the original defect.
I do agree that the security reports often exaggerate the severity of
having TRACE enabled.
Re: TRACE still enabled by default
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2012 2:59 PM, Mark Montague wrote:
> On March 21, 2012 15:33 , "Roy T. Fielding" <fi...@gbiv.com> wrote:
>> TRACE won't work at all if the most popular end-point doesn't support it.
>
> Why would this be a bad thing? Or, to phrase it another way, what are the situations in
> which it is desirable that TRACE be already-enabled on a web server as opposed to having
> the owner of the web server enable the TRACE method in response to a specific debugging need?
Because, if you do NOT own the end-point, but are trying to debug a fault
in a proxy which you DO own, then the lack of support in the upstream
proxies or origin server leave you no ability to perform this diagnostic.
The output was never intended for unfiltered display. IIS provided for
the TRACE results to be emitted to the browser with no consideration to
cross-site scripting implications. There WAS a browser bug, but never
an actual flaw with the protocol or Apache implementation. Most of the
security reports and scanner output mischaracterizes the original defect.
Re: TRACE still enabled by default
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Mar 21, 2012 at 16:23, Reindl Harald <h....@thelounge.net> wrote:
> Am 21.03.2012 21:02, schrieb Greg Stein:
>> On Wed, Mar 21, 2012 at 15:59, Mark Montague <ma...@catseye.org> wrote:
>>> On March 21, 2012 15:33 , "Roy T. Fielding" <fi...@gbiv.com> wrote:
>>>>
>>>> TRACE won't work at all if the most popular end-point doesn't support it.
>>>
>>> Why would this be a bad thing? Or, to phrase it another way, what are the
>>> situations in which it is desirable that TRACE be already-enabled on a web
>>> server as opposed to having the owner of the web server enable the TRACE
>>> method in response to a specific debugging need?
>>
>> Roy means that if we don't set the precedent for TRACE being present
>> and how it is supposed to work, then nobody else will. The Apache HTTP
>> server is effectively the embodiment and leader of the HTTP
>> specification.
>
> and now tell us ONE real world reason to
> enable it BY DEFAULT
Don't get ALL-CAPS angry at me. There's no call for that. It just
seemed that Mark wasn't understanding Roy's comment, so I tried to
elucidate.
-g
Re: TRACE still enabled by default
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.03.2012 21:02, schrieb Greg Stein:
> On Wed, Mar 21, 2012 at 15:59, Mark Montague <ma...@catseye.org> wrote:
>> On March 21, 2012 15:33 , "Roy T. Fielding" <fi...@gbiv.com> wrote:
>>>
>>> TRACE won't work at all if the most popular end-point doesn't support it.
>>
>> Why would this be a bad thing? Or, to phrase it another way, what are the
>> situations in which it is desirable that TRACE be already-enabled on a web
>> server as opposed to having the owner of the web server enable the TRACE
>> method in response to a specific debugging need?
>
> Roy means that if we don't set the precedent for TRACE being present
> and how it is supposed to work, then nobody else will. The Apache HTTP
> server is effectively the embodiment and leader of the HTTP
> specification.
and now tell us ONE real world reason to
enable it BY DEFAULT
Re: TRACE still enabled by default
Posted by Mark Montague <ma...@catseye.org>.
On March 21, 2012 16:02 , Greg Stein <gs...@gmail.com> wrote:
>>> TRACE won't work at all if the most popular end-point doesn't support it.
>> Why would this be a bad thing? Or, to phrase it another way, what are the
>> situations in which it is desirable that TRACE be already-enabled on a web
>> server as opposed to having the owner of the web server enable the TRACE
>> method in response to a specific debugging need?
> Roy means that if we don't set the precedent for TRACE being present
> and how it is supposed to work, then nobody else will. The Apache HTTP
> server is effectively the embodiment and leader of the HTTP
> specification.
Yes, that was clear. But why would setting a precedent and leading the
way for TRACE only being present when explicitly enabled by the owner of
a specific web server be bad? For the sake of discussion, what real
world problems -- troubleshooting, debugging, or other problems -- would
such a course of action actually cause?
--
Mark Montague
mark@catseye.org
Re: TRACE still enabled by default
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Mar 21, 2012 at 15:59, Mark Montague <ma...@catseye.org> wrote:
> On March 21, 2012 15:33 , "Roy T. Fielding" <fi...@gbiv.com> wrote:
>>
>> TRACE won't work at all if the most popular end-point doesn't support it.
>
> Why would this be a bad thing? Or, to phrase it another way, what are the
> situations in which it is desirable that TRACE be already-enabled on a web
> server as opposed to having the owner of the web server enable the TRACE
> method in response to a specific debugging need?
Roy means that if we don't set the precedent for TRACE being present
and how it is supposed to work, then nobody else will. The Apache HTTP
server is effectively the embodiment and leader of the HTTP
specification.
Cheers,
-g
Re: TRACE still enabled by default
Posted by Mark Montague <ma...@catseye.org>.
On March 21, 2012 15:33 , "Roy T. Fielding" <fi...@gbiv.com> wrote:
> TRACE won't work at all if the most popular end-point doesn't support it.
Why would this be a bad thing? Or, to phrase it another way, what are
the situations in which it is desirable that TRACE be already-enabled on
a web server as opposed to having the owner of the web server enable the
TRACE method in response to a specific debugging need?
--
Mark Montague
mark@catseye.org
Re: TRACE still enabled by default
Posted by Reindl Harald <h....@thelounge.net>.
Am 22.03.2012 16:17, schrieb Tom Evans:
> On Thu, Mar 22, 2012 at 3:15 PM, Eric Covener <co...@gmail.com> wrote:
>>> How about providing a simpler way of turning it off, rather than
>>> turning it off by default? Arbitrarily, it seems, you can't use Limit
>>> or LimitExcept to restrict it, and instead have to use a RewriteRule.
>>>
>>
>> We've had TraceEnable for a while:
>> http://httpd.apache.org/docs/2.2/mod/core.html#traceenable
>
> Now I hide in shame :/
the whole discussion is about exactly this option
which defaults to ON and most people do even not
know that TRACE exists at all even after reading
over years many many articles about server-hardening
Re: TRACE still enabled by default
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Mar 22, 2012 at 3:15 PM, Eric Covener <co...@gmail.com> wrote:
>> How about providing a simpler way of turning it off, rather than
>> turning it off by default? Arbitrarily, it seems, you can't use Limit
>> or LimitExcept to restrict it, and instead have to use a RewriteRule.
>>
>
> We've had TraceEnable for a while:
> http://httpd.apache.org/docs/2.2/mod/core.html#traceenable
Now I hide in shame :/
Cheers
Tom
Re: TRACE still enabled by default
Posted by Eric Covener <co...@gmail.com>.
> How about providing a simpler way of turning it off, rather than
> turning it off by default? Arbitrarily, it seems, you can't use Limit
> or LimitExcept to restrict it, and instead have to use a RewriteRule.
>
We've had TraceEnable for a while:
http://httpd.apache.org/docs/2.2/mod/core.html#traceenable
Re: TRACE still enabled by default
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 22, 2012, at 11:07 AM, Tom Evans wrote:
> On Wed, Mar 21, 2012 at 7:33 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>> TRACE won't work at all if the most popular end-point doesn't support it.
>>
>> If folks want to protect clients (including gateways) against their own
>> stupidity regarding what they choose to send in a TRACE request, then
>> do so by selectively removing some lines from the response and I will
>> try to update the standard accordingly.
>>
>> Turning it off by default is not an option. I will veto that.
>>
>> ....Roy
>
> How about providing a simpler way of turning it off, rather than
> turning it off by default? Arbitrarily, it seems, you can't use Limit
> or LimitExcept to restrict it, and instead have to use a RewriteRule.
>
Simpler than 'TraceEnable off' ??
Re: TRACE still enabled by default
Posted by Tom Evans <te...@googlemail.com>.
On Wed, Mar 21, 2012 at 7:33 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> TRACE won't work at all if the most popular end-point doesn't support it.
>
> If folks want to protect clients (including gateways) against their own
> stupidity regarding what they choose to send in a TRACE request, then
> do so by selectively removing some lines from the response and I will
> try to update the standard accordingly.
>
> Turning it off by default is not an option. I will veto that.
>
> ....Roy
How about providing a simpler way of turning it off, rather than
turning it off by default? Arbitrarily, it seems, you can't use Limit
or LimitExcept to restrict it, and instead have to use a RewriteRule.
Cheers
Tom
Re: TRACE still enabled by default
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 21, 2012, at 5:33 AM, Jim Jagielski wrote:
> On Mar 20, 2012, at 3:04 PM, Stefan Fritsch wrote:
>
>> On Saturday 17 March 2012, Roy T. Fielding wrote:
>>>> We still enable TRACE by default.
>>>>
>>>>
>>>>
>>>> Is this useful enough to justify making every other poor sap with
>>>> a security scanner have to manually turn it off?
>>>
>>> Yes.
>>>
>>>> I'm hoping 2.4.x is early enough in life where flipping this
>>>> wouldn't be too astonishing.
>>>
>>> I don't change protocols based on fool security researchers and
>>> their failure to correctly direct security reports. TRACE is not
>>> a vulnerability.
>>
>> That doesn't mean that it's a good idea to have it on by default. I
>> can't remember ever having needed it for debugging. While it may
>> actually be useful in reverse-proxy situations, it is usually
>> necessary to disable it there because one does not want to leak
>> internal information like the private IPs from X-Forwarded-For.
>>
>> It can also compound security issues in webapps. In general, one can
>> say that it increases the attack surface a web server presents to the
>> internet. I think it is a good idea to make it default to off.
>>
>
> I agree w/ Roy that having our defaults be non-compliant is
> bad, and actions which seem to imply that the idea that TRACE
> is a vulnerability is valid should be avoided.
TRACE won't work at all if the most popular end-point doesn't support it.
If folks want to protect clients (including gateways) against their own
stupidity regarding what they choose to send in a TRACE request, then
do so by selectively removing some lines from the response and I will
try to update the standard accordingly.
Turning it off by default is not an option. I will veto that.
....Roy
Re: TRACE still enabled by default
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 20, 2012, at 3:04 PM, Stefan Fritsch wrote:
> On Saturday 17 March 2012, Roy T. Fielding wrote:
>>> We still enable TRACE by default.
>>>
>>>
>>>
>>> Is this useful enough to justify making every other poor sap with
>>> a security scanner have to manually turn it off?
>>
>> Yes.
>>
>>> I'm hoping 2.4.x is early enough in life where flipping this
>>> wouldn't be too astonishing.
>>
>> I don't change protocols based on fool security researchers and
>> their failure to correctly direct security reports. TRACE is not
>> a vulnerability.
>
> That doesn't mean that it's a good idea to have it on by default. I
> can't remember ever having needed it for debugging. While it may
> actually be useful in reverse-proxy situations, it is usually
> necessary to disable it there because one does not want to leak
> internal information like the private IPs from X-Forwarded-For.
>
> It can also compound security issues in webapps. In general, one can
> say that it increases the attack surface a web server presents to the
> internet. I think it is a good idea to make it default to off.
>
I agree w/ Roy that having our defaults be non-compliant is
bad, and actions which seem to imply that the idea that TRACE
is a vulnerability is valid should be avoided.
Re: TRACE still enabled by default
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-03-20 20:04, Stefan Fritsch wrote:
> ...
> It can also compound security issues in webapps. In general, one can
^^^^^^^
How so? When you say "webapps", are you referring to something not
running via script/XHR?
Best regards, Julian
Re: TRACE still enabled by default
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 17 March 2012, Roy T. Fielding wrote:
> > We still enable TRACE by default.
> >
> >
> >
> > Is this useful enough to justify making every other poor sap with
> > a security scanner have to manually turn it off?
>
> Yes.
>
> > I'm hoping 2.4.x is early enough in life where flipping this
> > wouldn't be too astonishing.
>
> I don't change protocols based on fool security researchers and
> their failure to correctly direct security reports. TRACE is not
> a vulnerability.
That doesn't mean that it's a good idea to have it on by default. I
can't remember ever having needed it for debugging. While it may
actually be useful in reverse-proxy situations, it is usually
necessary to disable it there because one does not want to leak
internal information like the private IPs from X-Forwarded-For.
It can also compound security issues in webapps. In general, one can
say that it increases the attack surface a web server presents to the
internet. I think it is a good idea to make it default to off.
Re: TRACE still enabled by default
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 21, 2012, at 8:39 AM, Reindl Harald wrote:
>
>
> Am 17.03.2012 10:24, schrieb Roy T. Fielding:
>> On Mar 16, 2012, at 7:18 AM, Eric Covener wrote:
>>
>>> We still enable TRACE by default.
>>>
>>> Is this useful enough to justify making every other poor sap with a
>>> security scanner have to manually turn it off?
>>
>> Yes.
>>
>>> I'm hoping 2.4.x is early enough in life where flipping this wouldn't
>>> be too astonishing.
>>
>> I don't change protocols based on fool security researchers and their
>> failure to correctly direct security reports. TRACE is not a vulnerability.
>
> 1 out of a million servers needs TRACE enabled
>
> it was ALWAYS a good idea to disable ANYTHING by default
> what is not really needed and this principle will stay
>
If admin's want that, then they can set that up. But there's
no reason for the default to be something that isn't warranted.
Re: TRACE still enabled by default
Posted by Noel Butler <no...@ausics.net>.
On Wed, 2012-03-21 at 14:48 +0100, Reindl Harald wrote:
> > Nessus, despite I do like it, and as it is a respected industry standard, has its fair share of false positives,
> > for simple example, look at FTP, running a public FTP server you get a severity "medium" warning, I mean like..
> > WTF... if anything, it should be an "info" , which brings me to their LOW ratings, they need to introduce an INFO
> > level, because 95% of "low" are not issues at all.
>
> this is a different story
> openVAS has a info-level and i guess Nessus too because openVAS is a fork
>
> that services are treated as medium is fine because if
> nessus finds a service and you do not know that it is
> running -> problem, it is the job of the auditor flag
> the port as "info, OK"
>
I don't consider fine, as it does not report same of other services
running, we run an IRC server, and even it gets scored a low :)
BTW, I stand corrected, just asked Ron and he told me nessus has INFO
levels as of nessus 5.
Re: TRACE still enabled by default
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.03.2012 14:41, schrieb Noel Butler:
> On Wed, 2012-03-21 at 13:55 +0100, Reindl Harald wrote:
>>
> Firstly, as stated previously, I agree TRACE should be disabled by default because those that need it are probably
> at about 1 in 10000, and I'd like to see a proper vote called on it :) however...
>>
>> fact is that nessus-scans usually complaining about TRACE on
>
> Nessus, despite I do like it, and as it is a respected industry standard, has its fair share of false positives,
> for simple example, look at FTP, running a public FTP server you get a severity "medium" warning, I mean like..
> WTF... if anything, it should be an "info" , which brings me to their LOW ratings, they need to introduce an INFO
> level, because 95% of "low" are not issues at all.
this is a different story
openVAS has a info-level and i guess Nessus too because openVAS is a fork
that services are treated as medium is fine because if
nessus finds a service and you do not know that it is
running -> problem, it is the job of the auditor flag
the port as "info, OK"
but he will NOT do this if it is a simple config-option
disable TRACE and the application does not need it
so the defaults has to be sane
nothing more to say -> not my problem, i have disabled it
Re: TRACE still enabled by default
Posted by Noel Butler <no...@ausics.net>.
On Wed, 2012-03-21 at 13:55 +0100, Reindl Harald wrote:
>
Firstly, as stated previously, I agree TRACE should be disabled by
default because those that need it are probably at about 1 in 10000, and
I'd like to see a proper vote called on it :) however...
>
> fact is that nessus-scans usually complaining about TRACE on
Nessus, despite I do like it, and as it is a respected industry
standard, has its fair share of false positives, for simple example,
look at FTP, running a public FTP server you get a severity "medium"
warning, I mean like.. WTF... if anything, it should be an "info" ,
which brings me to their LOW ratings, they need to introduce an INFO
level, because 95% of "low" are not issues at all.
Re: TRACE still enabled by default
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.03.2012 13:48, schrieb Tim Bannister:
> On 21 Mar 2012, at 12:39, Reindl Harald wrote:
>
>> 1 out of a million servers needs TRACE enabled
>>
>> it was ALWAYS a good idea to disable ANYTHING by default what is not really needed and this principle will stay
>
> inetd normally ships with echo not running, but kernels usually ship with ICMP enabled.
> I think TRACE is more like ICMP echo than tcp/7 echo.
strange comparision
> If a distribution wants to ship a default configuration that
> disables TRACE, isn't that enough?
no, because distributions in the most cases are expecting
that the upstream defaults are usefull and have reason
> The issue is naïve / lazy server admins, and almost all of those
> will install httpd from a distribution
OK, so you call me "lazy" and "naive" because i heard
about TRACE the first time after complaints of a security
audit of a big customer while i spent many nights to search
about server hardening the last years?
fact is that nessus-scans usually complaining about TRACE on
and depending on the policies of the customer you MUST disable
it while you even not knew waht it is, that it is enabled
and hell i do not find any case where it could be useful
Re: TRACE still enabled by default
Posted by Tim Bannister <is...@jellybaby.net>.
On 21 Mar 2012, at 12:39, Reindl Harald wrote:
> 1 out of a million servers needs TRACE enabled
>
> it was ALWAYS a good idea to disable ANYTHING by default what is not really needed and this principle will stay
inetd normally ships with echo not running, but kernels usually ship with ICMP enabled. I think TRACE is more like ICMP echo than tcp/7 echo.
If a distribution wants to ship a default configuration that disables TRACE, isn't that enough? The issue is naïve / lazy server admins, and almost all of those will install httpd from a distribution.
--
Tim Bannister – isoma@jellybaby.net
Re: TRACE still enabled by default
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.03.2012 10:24, schrieb Roy T. Fielding:
> On Mar 16, 2012, at 7:18 AM, Eric Covener wrote:
>
>> We still enable TRACE by default.
>>
>> Is this useful enough to justify making every other poor sap with a
>> security scanner have to manually turn it off?
>
> Yes.
>
>> I'm hoping 2.4.x is early enough in life where flipping this wouldn't
>> be too astonishing.
>
> I don't change protocols based on fool security researchers and their
> failure to correctly direct security reports. TRACE is not a vulnerability.
1 out of a million servers needs TRACE enabled
it was ALWAYS a good idea to disable ANYTHING by default
what is not really needed and this principle will stay
Re: TRACE still enabled by default
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 16, 2012, at 7:18 AM, Eric Covener wrote:
> We still enable TRACE by default.
>
> Is this useful enough to justify making every other poor sap with a
> security scanner have to manually turn it off?
Yes.
> I'm hoping 2.4.x is early enough in life where flipping this wouldn't
> be too astonishing.
I don't change protocols based on fool security researchers and their
failure to correctly direct security reports. TRACE is not a vulnerability.
....Roy
Re: TRACE still enabled by default
Posted by Noel Butler <no...@ausics.net>.
On Fri, 2012-03-16 at 10:18 -0400, Eric Covener wrote:
> We still enable TRACE by default.
>
> Is this useful enough to justify making every other poor sap with a
> security scanner have to manually turn it off?
>
> I'm hoping 2.4.x is early enough in life where flipping this wouldn't
> be too astonishing.
+1