Bug 52751 - Optimized configuration of the system info displayed in the default error page
Summary: Optimized configuration of the system info displayed in the default error page
Status: RESOLVED DUPLICATE of bug 56383
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: trunk
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-23 17:34 UTC by polina.genova
Modified: 2014-05-08 11:32 UTC (History)
1 user (show)



Attachments
Patch in ErrorReportValve.java and docu page + 2 screenshots (96.44 KB, application/x-zip-compressed)
2012-02-23 17:34 UTC, polina.genova
Details

Note You need to log in before you can comment on or make changes to this bug.
Description polina.genova 2012-02-23 17:34:32 UTC
Created attachment 28372 [details]
Patch in ErrorReportValve.java and docu page + 2 screenshots

Hi,
Here's an enhancement patch for the system info displayed in the default error page and the way it is retrieved.  The patch makes it possible to reuse the value of the server header configuration if it is available. Thus the system information revealed in the server header and the default error page would be consistent and would be easier to maintain.  
It is known that system information disclosure is an easy to fix, yet serious security flaw as it opens the door to all attackers who wouldn’t resist exploiting  known vulnerabilities for the given system version. That’s why it is recommended (in all Tomcat security configuration guides) to customize both the server header and the server.info property. On the other hand, with this enhancement the protection from system information leakage can be done easier - with only one configuration and without worrying about the side effects of custom changes in the server.info property. 
Except the patch there are also two screenshots attached: 
–Default error page when server header is configured
-Default error page when server header is not configured

Best Regards,
Polina
Comment 1 Mark Thomas 2012-03-20 21:54:42 UTC
Comment on attachment 28372 [details]
Patch in ErrorReportValve.java and docu page + 2 screenshots

Correct patch MIME type so BZ doesn't try to display it.
Comment 2 Mark Thomas 2012-03-20 22:11:07 UTC
It is very rare for an attacker to identify the specific Tomcat version and then target a known vulnerability. It is much more common to see every known vulnerability probed (for a range of servers) rather than the more targeted attack described in the patch. I therefore see little point in hiding the version number. I'd go further than that and say I would prefer to see the exact Tomcat version in the server header since it provides more assistance to debugging/monitoring efforts than it does harm.

Even if the version number is hidden there are plenty of other clues to the exact version number, particularly the line numbers in any stack trace.

Rather than address this specific issue, I'd prefer to see a general solution to bug 41007 that allowed custom error pages to be specified without having to write a custom valve.
Comment 3 Violeta Georgieva 2012-03-21 20:23:15 UTC
Hi,

I agreed with your points.

Unfortunately in some installation scenarios we do not have either access to the jar files or permissions to restart the system in order to configure the default error page footer, manipulating directly the jar file. 

With this small improvement Tomcat will provide convenient way for configuring default error page footer not only through the server.xml but also during runtime using provided Connectors MBeans.

What do you think?

Regards
Violeta Georgieva
Comment 4 Violeta Georgieva 2012-03-21 20:25:11 UTC
Comment on attachment 28372 [details]
Patch in ErrorReportValve.java and docu page + 2 screenshots

Corrected patch MIME type
Comment 5 Konstantin Kolinko 2012-03-22 13:22:16 UTC
I am OK with the patch, but there is a problem: it would not work if Tomcat is accessed through AJP protocol.  The patch relies on the use of AbstractHttp11Protocol to get the "server" setting.

Maybe the "server" attribute should be exposed through AbstractProtocol or Endpoint or elsewhere.

I had a fear that the default value of "server" attribute which is documented to be "Apache-Coyote/1.1" will be visible here. Actually it should not be the case here. The "Apache-Coyote/1.1" string (aka Constants.SERVER_BYTES) is used by AbstractHttp11Processor only if the server attribute is null.


> I would prefer to see the exact Tomcat version in the server header

+1.

I wonder though how coyote can get Tomcat version. Wouldn't that add an unwanted dependency between components.


> particularly the line numbers in any stack trace.

The stack traces can be hidden. Most error pages do not display them. One can configure a custom error page for error 500.

> manipulating directly the jar file.

Note, that there is no need to manipulate the jar file! One can create the following file:
CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties

(I thought it is mentioned in the FAQ, but cannot find it at this moment). It is written here:
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Valves
Comment 6 Violeta Georgieva 2012-03-22 13:37:42 UTC
(In reply to comment #5)
> Maybe the "server" attribute should be exposed through AbstractProtocol or
> Endpoint or elsewhere.

I'll check that.

> Note, that there is no need to manipulate the jar file! One can create the
> following file:
> CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties

Unforutnately it is not so easy for us. We (Eclipse Virgo) are embeding Tomcat. Classloaders are a bit different in OSGi environment.
Comment 7 polina.genova 2012-04-11 14:41:25 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Maybe the "server" attribute should be exposed through AbstractProtocol or
> > Endpoint or elsewhere.
> I'll check that.

Thanks for the hint!

Indeed using
    server = ((AbstractAjpProtocol) response.getConnector().getProtocolHandler()).getProperty("server") 
will right away do the job in the case of AJP connector (if there is server attribute configured for it).

The problem is that the server attribute is currently not explicitly handled for the AJP connector (unlike the HttpConnecor), meaning this attribute is not documented and its value is not read or used anywhere in the AJP connector implementation. 
Do you think we should revise this behavior and add server attribute handling for the AJP connector?
Comment 8 polina.genova 2012-05-03 08:27:50 UTC
Hi,

What do you think of my previous comment – in this case should I provide server attribute handling for the AJP connector in addition to the given patch?

I’m looking forward hearing from you, whatever the outcome is. 

Thanks in advance,
Polina
Comment 9 Violeta Georgieva 2014-04-25 11:19:26 UTC
Hi Polina,

Check Bug 56383.
Do you think that the enhancement solves your use case?

Regards
Violeta
Comment 10 polina.genova 2014-05-08 08:58:24 UTC
Hi Violeta, 

Yes, the given solution perfectly solves my use case.

Thanks and regards,
Polina
Comment 11 Violeta Georgieva 2014-05-08 11:32:27 UTC
Ok 
Thanks

Violeta

*** This bug has been marked as a duplicate of bug 56383 ***