Apache Tomcat 5.x vulnerabilities

This page lists all security vulnerabilities fixed in released versions
of Apache Tomcat 5.x. Each vulnerability is given a
security impact rating by the Apache
Tomcat security team — please note that this rating may vary from
platform to platform. We also list the versions of Apache Tomcat the flaw
is known to affect, and where a flaw has not been verified list the
version with a question mark.

Note: Vulnerabilities that are not Tomcat vulnerabilities
but have either been incorrectly reported against Tomcat or where Tomcat
provides a workaround are listed at the end of this page.

Please note that Tomcat 5.0.x and 5.5.x are no longer supported. Further
vulnerabilities in the 5.0.x and 5.5.x branches will not be fixed. Users
should upgrade to 7.x or later to obtain security fixes. Vulnerabilities
fixed in Tomcat 5.5.26 onwards have not been assessed to determine if
they are present in the 5.0.x branch.

Please note that binary patches are never provided. If you need to
apply a source code patch, use the building instructions for the
Apache Tomcat version that you are using. For Tomcat 5.5 those are
building.html
in documentation (webapps/tomcat-docs subdirectory of
a binary distributive) and BUILDING.txt file in a source
distributive.

If you need help on building or configuring Tomcat or other help on
following the instructions to mitigate the known vulnerabilities listed
here, please send your questions to the public
Tomcat Users mailing list

If you have encountered an unlisted security vulnerability or other
unexpected behaviour that has security
impact, or if the descriptions here are incomplete,
please report them privately to the
Tomcat Security Team. Thank you.

The first issue was reported by Tilmann Kuhn to the Tomcat security team
on 19 July 2012. The second and third issues were discovered by the
Tomcat security team during the resulting code review. All three issues
were made public on 5 November 2012.

Affects: 5.5.0-5.5.35

released 16 Jan 2012 Fixed in Apache Tomcat 5.5.35

Analysis of the recent hash collision vulnerability identified unrelated
inefficiencies with Apache Tomcat's handling of large numbers of
parameters and parameter values. These inefficiencies could allow an
attacker, via a specially crafted request, to cause large amounts of CPU
to be used which in turn could create a denial of service. The issue was
addressed by modifying the Tomcat parameter handling code to efficiently
process large numbers of parameters and parameter values.

released 22 Sep 2011 Fixed in Apache Tomcat 5.5.34

Note: Mitre elected to break this issue down into multiple issues and
have allocated the following additional references to parts of this
issue:
CVE-2011-5062,
CVE-2011-5063 and
CVE-2011-5064. The Apache Tomcat security team will
continue to treat this as a single issue using the reference
CVE-2011-1184.

The implementation of HTTP DIGEST authentication was discovered to have
several weaknesses:

replay attacks were permitted

server nonces were not checked

client nonce counts were not checked

qop values were not checked

realm values were not checked

the server secret was hard-coded to a known string

The result of these weaknesses is that DIGEST authentication was only as
secure as BASIC authentication.

When using the MemoryUserDatabase (based on tomcat-users.xml) and
creating users via JMX, an exception during the user creation process may
trigger an error message in the JMX client that includes the user's
password. This error message is also written to the Tomcat logs. User
passwords are visible to administrators with JMX access and/or
administrators with read access to the tomcat-users.xml file. Users that
do not have these permissions but are able to read log files may be able
to discover a user's password.

Tomcat provides support for sendfile with the HTTP APR
connector. sendfile is used automatically for content served via the
DefaultServlet and deployed web applications may use it directly via
setting request attributes. These request attributes were not validated.
When running under a security manager, this lack of validation allowed a
malicious web application to do one or more of the following that would
normally be prevented by a security manager:

return files to users that the security manager should make
inaccessible

terminate (via a crash) the JVM

Additionally, these vulnerabilities only occur when all of the following
are true:

Due to a bug in the capabilities code, jsvc (the service wrapper for
Linux that is part of the Commons Daemon project) does not drop
capabilities allowing the application to access files and directories
owned by superuser. This vulnerability only occurs when all of the
following are true:

Tomcat is running on a Linux operating system

jsvc was compiled with libcap

-user parameter is used

Affected Tomcat versions shipped with source files for jsvc that included
this vulnerability.

Apache Tomcat supports the AJP protocol which is used with reverse
proxies to pass requests and associated data about the request from the
reverse proxy to Tomcat. The AJP protocol is designed so that when a
request includes a request body, an unsolicited AJP message is sent to
Tomcat that includes the first part (or possibly all) of the request
body. In certain circumstances, Tomcat did not process this message as a
request body but as a new request. This permitted an attacker to have
full control over the AJP message permitting authentication bypass and
information disclosure. This vulnerability only occurs when all of the
following are true:

Configure both Tomcat and the reverse proxy to use a shared secret.
(It is "request.secret" attribute in AJP <Connector>,
"worker.workername.secret" directive for mod_jk.
The mod_proxy_ajp module currently does not support shared secrets).

Use the org.apache.jk.server.JkCoyoteHandler (BIO) AJP connector
implementation.
(It is automatically selected if you do not have Tomcat-Native library
installed. It can be also selected explicitly:
<Connector protocol="org.apache.jk.server.JkCoyoteHandler">).

released 9 Jul 2010 Fixed in Apache Tomcat 5.5.30

When running under a SecurityManager, access to the file system is
limited but web applications are granted read/write permissions to the
work directory. This directory is used for a variety of temporary files
such as the intermediate files generated when compiling JSPs to Servlets.
The location of the work directory is specified by a ServletContect
attribute that is meant to be read-only to web applications. However,
due to a coding error, the read-only setting was not applied. Therefore,
a malicious web application may modify the attribute before Tomcat
applies the file permissions. This can be used to grant read/write
permissions to any area on the file system which a malicious web
application may then take advantage of. This vulnerability is only
applicable when hosting web applications from untrusted sources such as
shared hosting environments.

This was discovered by the Tomcat security team on 12 Oct 2010 and
made public on 5 Feb 2011.

Affects: 5.5.0-5.5.29

Important: Remote Denial Of Service and Information Disclosure
VulnerabilityCVE-2010-2227

Several flaws in the handling of the 'Transfer-Encoding' header were
found that prevented the recycling of a buffer. A remote attacker could
trigger this flaw which would cause subsequent requests to fail and/or
information to leak between requests. This flaw is mitigated if Tomcat is
behind a reverse proxy (such as Apache httpd 2.2) as the proxy should
reject the invalid transfer encoding header.

The WWW-Authenticate HTTP header for BASIC and DIGEST
authentication includes a realm name. If a
<realm-name> element is specified for the application
in web.xml it will be used. However, a <realm-name>
is not specified then Tomcat will generate realm name using the code
snippet request.getServerName() + ":" +
request.getServerPort(). In some circumstances this can expose
the local host name or IP address of the machine running Tomcat.

released 20 Apr 2010 Fixed in Apache Tomcat 5.5.29

When deploying WAR files, the WAR files were not checked for directory
traversal attempts. This allows an attacker to create arbitrary content
outside of the web root by including entries such as
../../bin/catalina.sh in the WAR.

By default, Tomcat automatically deploys any directories placed in a
host's appBase. This behaviour is controlled by the autoDeploy attribute
of a host which defaults to true. After a failed undeploy, the remaining
files will be deployed as a result of the autodeployment process.
Depending on circumstances, files normally protected by one or more
security constraints may be deployed without those security constraints,
making them accessible without authentication. This issue only affects
Windows platforms

When deploying WAR files, the WAR file names were not checked for
directory traversal attempts. For example, deploying and undeploying
...war allows an attacker to cause the deletion of the
current contents of the host's work directory which may cause problems
for currently running applications.

The Windows installer defaults to a blank password for the administrative
user. If this is not changed during the install process, then by default
a user is created with the name admin, roles admin and manager and a
blank password.

Affects: 5.5.0-5.5.28

This was first reported to the Tomcat security team on 26 Oct 2009 and
made public on 9 Nov 2009.

released 4 Sep 2009 Fixed in Apache Tomcat 5.5.28

When using a RequestDispatcher obtained from the Request, the target path
was normalised before the query string was removed. A request that
included a specially crafted request parameter could be used to access
content that would otherwise be protected by a security constraint or by
locating it in under the WEB-INF directory.

If Tomcat receives a request with invalid headers via the Java AJP
connector, it does not return an error and instead closes the AJP
connection. In case this connector is member of a mod_jk load balancing
worker, this member will be put into an error state and will be blocked
from use for approximately one minute. Thus the behaviour can be used for
a denial of service attack using a carefully crafted request.

Due to insufficient error checking in some authentication classes, Tomcat
allows for the enumeration (brute force testing) of user names by
supplying illegally URL encoded passwords. The attack is possible if FORM
based authentication (j_security_check) is used with the MemoryRealm.
Note that in early versions, the DataSourceRealm and JDBCRealm were also
affected.

Bugs 29936 and 45933 allowed a web application
to replace the XML parser used by
Tomcat to process web.xml, context.xml and tld files. In limited
circumstances these bugs may allow a rogue web application to view and/or
alter the web.xml, context.xml and tld files of other web applications
deployed on the Tomcat instance.

released 8 Sep 2008 Fixed in Apache Tomcat 5.5.27

The message argument of HttpServletResponse.sendError() call is not only
displayed on the error page, but is also used for the reason-phrase of
HTTP response. This may include characters that are illegal in HTTP
headers. It is possible for a specially crafted message to result in
arbitrary content being injected into the HTTP response. For a successful
XSS attack, unfiltered user supplied data must be included in the message
argument.

The Host Manager web application did not escape user provided data before
including it in the output. This enabled a XSS attack. This application
now filters the data before use. This issue may be mitigated by logging
out (closing the browser) of the application once the management tasks
have been completed.

When using a RequestDispatcher the target path was normalised before the
query string was removed. A request that included a specially crafted
request parameter could be used to access content that would otherwise be
protected by a security constraint or by locating it in under the WEB-INF
directory.

The JULI logging component allows web applications to provide their own
logging configurations. The default security policy does not restrict
this configuration and allows an untrusted web application to add files
or overwrite existing files where the Tomcat process has the necessary
file permissions to do so.

When Tomcat's WebDAV servlet is configured for use with a context and
has been enabled for write, some WebDAV requests that specify an entity
with a SYSTEM tag can result in the contents of arbitary files being
returned to the client.

When using the native (APR based) connector, connecting to the SSL port
using netcat and then disconnecting without sending any data will cause
tomcat to handle a duplicate copy of one of the recent requests.

Affects: 5.5.11-5.5.25

released 8 Sep 2007 Fixed in Apache Tomcat 5.5.25, 5.0.SVN

JSPs within the examples web application did not escape user provided
data before including it in the output. This enabled a XSS attack. These
JSPs now filter the data before use. This issue may be mitigated by
undeploying the examples web application. Note that it is recommended
that the examples web application is not installed on a production
system.

The Manager and Host Manager web applications did not escape user
provided data before including it in the output. This enabled a XSS
attack. These applications now filter the data before use. This issue may
be mitigated by logging out (closing the browser) of the application once
the management tasks have been completed.

Not released Fixed in Apache Tomcat 5.5.24, 5.0.SVN

The JSP and Servlet included in the sample application within the Tomcat
documentation webapp did not escape user provided data before including
it in the output. This enabled a XSS attack. These pages have been
simplified not to use any user provided data in the output.

Affects: 5.0.0-5.0.30, 5.5.0-5.5.23

released 9 Mar 2007 Fixed in Apache Tomcat 5.5.23, 5.0.SVN

Requests with multiple content-length headers should be rejected as
invalid. When multiple components (firewalls, caches, proxies and Tomcat)
process a sequence of requests where one or more requests contain
multiple content-length headers and several components do not
reject the request and make different decisions as to which
content-length header to use an attacker can poison a web-cache, perform
an XSS attack and obtain sensitive information from requests other then
their own. Tomcat now returns 400 for requests with multiple
content-length headers.

Affects: 5.0.0-5.0.30, 5.5.0-5.5.22

not released Fixed in Apache Tomcat 5.5.22, 5.0.SVN

The fix for this issue was insufficient. A fix was also required in the
JK connector module for httpd. See CVE-2007-1860 for further
information.

Tomcat permits '\', '%2F' and '%5C' as path delimiters. When Tomcat is used
behind a proxy (including, but not limited to, Apache HTTP server with
mod_proxy and mod_jk) configured to only proxy some contexts, a HTTP request
containing strings like "/\../" may allow attackers to work around the context
restriction of the proxy, and access the non-proxied contexts.

The following Java system properties have been added to Tomcat to provide
additional control of the handling of path delimiters in URLs (both options
default to false):

not released Fixed in Apache Tomcat 5.5.21, 5.0.SVN

Web pages that display the Accept-Language header value sent by the
client are susceptible to a cross-site scripting attack if they assume
the Accept-Language header value conforms to RFC 2616. Under normal
circumstances this would not be possible to exploit, however older
versions of Flash player were known to allow carefully crafted malicious
Flash files to make requests with such custom headers. When generating
the response for getLocale() and getLocales(),
Tomcat now ignores values for Accept-Language headers that do not conform
to RFC 2616. Applications that use the raw header values directly should
not assume that the headers conform to RFC 2616 and should filter the
values appropriately.

Affects: 5.0.0-5.0.30, 5.5.0-5.5.20

not released Fixed in Apache Tomcat 5.5.21

When using the SingleSignOn Valve via https the Cookie JSESSIONIDSSO is
transmitted without the "secure" attribute, resulting in it being
transmitted to any content that is - by purpose or error - requested via
http from the same server.

Bug
40771 may result in the disclosure of POSTed content from a previous
request. For a vulnerability to exist, the content read from the input
stream must be disclosed, eg via writing it to the response and committing
the response, before the ArrayIndexOutOfBoundsException occurs which will
halt processing of the request.

Fixed in Apache Tomcat 5.5.13, 5.0.SVN

This is expected behaviour when directory listings are enabled. The
semicolon (;) is the separator for path parameters so inserting one
before a file name changes the request into a request for a directory
with a path parameter. If directory listings are enabled, a directory
listing will be shown. In response to this and other directory listing
issues, directory listings were changed to be disabled by default.

The root cause is the relatively expensive calls required to generate
the content for the directory listings. If directory listings are
enabled, the number of files in each directory should be kept to a
minimum. In response to this issue, directory listings were changed to
be disabled by default. Additionally, a
patch has been proposed that would improve performance, particularly
for large directories, by caching directory listings.

Affects: 5.0.0-5.0.30, 5.5.0-5.5.12

Fixed in Apache Tomcat 5.5.7, 5.0.SVN

Various JSPs included as part of the JSP examples and the Tomcat Manager
are susceptible to a cross-site scripting attack as they do not escape
user provided data before including it in the returned page.

Affects: 5.0.0-5.0.30, 5.5.0-5.5.6

Fixed in Apache Tomcat 5.5.1

Bug 25835 can, in rare circumstances - this has only been reproduced
using a debugger to force a particular processing sequence for two threads -
allow a user from a non-permitted IP address to gain access to a context
that is protected with a valve that extends RequestFilterValve. This includes
the standard RemoteAddrValve and RemoteHostValve implementations.

Affects: 5.5.0 (5.0.x unknown)

Not a vulnerability in Tomcat

A JVM bug could cause Double conversion to hang JVM when accessing to a
form based security constrained page or any page that calls
javax.servlet.ServletRequest.getLocale() or
javax.servlet.ServletRequest.getLocales(). A specially crafted request
can be used to trigger a denial of service.

A work-around for this JVM bug was provided in
revision 1066318.
This work-around is included in Tomcat 5.5.33 onwards.

This was first reported to the Tomcat security team on 01 Feb 2011 and
made public on 31 Jan 2011.

A vulnerability exists in the TLS protocol that allows an attacker to
inject arbitrary requests into an TLS stream during renegotiation.

The TLS implementation used by Tomcat varies with connector. The blocking
IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation
provided by the JVM. The APR/native connector uses OpenSSL.

The BIO connector is vulnerable if the JSSE version used is vulnerable.
To workaround this until a fix is available in JSSE, a new connector
attribute allowUnsafeLegacyRenegotiation has been added to
the BIO connector. It should be set to false (the default)
to protect against this vulnerability.

The NIO connector is not vulnerable as it does not support
renegotiation.

Users should be aware that the impact of disabling renegotiation will
vary with both application and client. In some circumstances disabling
renegotiation may result in some clients being unable to access the
application.

A workaround was implemented in
revision 904851
that provided the new allowUnsafeLegacyRenegotiation
attribute. This work around is included in Tomcat 5.5.29 onwards.

Support for the new TLS renegotiation protocol (RFC 5746) that does not
have this security issue:

For connectors using JSSE implementation provided by JVM:
Added in Tomcat 5.5.33.
Requires JRE that supports RFC 5746. For Oracle JRE that is
known
to be 6u22 or later.

Originally reported as a Tomcat vulnerability the root cause of this
issue is that the JVM does not correctly decode UTF-8 encoded URLs to
UTF-8. This exposes a directory traversal vulnerability when the
connector uses URIEncoding="UTF-8". This directory traversal
is limited to the docBase of the web application.

If a context is configured with allowLinking="true" then the
directory traversal vulnerability is extended to the entire file system
of the host server.

It should also be noted that setting
useBodyEncodingForURI="true" has the same effect as setting
URIEncoding="UTF-8" when processing requests with bodies
encoded with UTF-8.

Although the root cause was quickly identified as a JVM issue and that it
affected multiple JVMs from multiple vendors, it was decided to report
this as a Tomcat vulnerability until such time as the JVM vendors
provided updates to resolve this issue. For further information on the
status of this issue for your JVM, contact your JVM vendor.

A workaround was implemented in
revision 681029
that protects against this and any similar character
encoding issues that may still exist in the JVM. This work around is
included in Tomcat 5.5.27 onwards.