It was possible to craft a
malformed chunk size as part of a chucked request that enabled an
unlimited amount of data to be streamed to the server, bypassing the
various size limits enforced on a request. This enabled a denial of
service attack.

The default servlet allows web
applications to define (at multiple levels) an XSLT to be used to format
a directory listing. When running under a security manager, the
processing of these was not subject to the same constraints as the web
application. This enabled a malicious web application to bypass the file
access constraints imposed by the security manager via the use of
external XML entities.

The code used to parse the
request content length header did not check for overflow in the result.
This exposed a request smuggling vulnerability when Tomcat was located
behind a reverse proxy that correctly processed the content length
header.

In limited circumstances it was
possible for a malicious web application to replace the XML parsers used
by Tomcat to process XSLTs for the default servlet, JSP documents, tag
library descriptors (TLDs) and tag plugin configuration files. The
injected XMl parser(s) could then bypass the limits imposed on XML
external entities and/or have visibility of the XML files processed for
other web applications deployed on the same Tomcat instance.

It was possible to craft a
malformed chunk size as part of a chucked request that enabled an
unlimited amount of data to be streamed to the server, bypassing the
various size limits enforced on a request. This enabled a denial of
service attack.

The default servlet allows web
applications to define (at multiple levels) an XSLT to be used to format
a directory listing. When running under a security manager, the
processing of these was not subject to the same constraints as the web
application. This enabled a malicious web application to bypass the file
access constraints imposed by the security manager via the use of
external XML entities.

The code used to parse the
request content length header did not check for overflow in the result.
This exposed a request smuggling vulnerability when Tomcat was located
behind a reverse proxy that correctly processed the content length
header.

In limited circumstances it was
possible for a malicious web application to replace the XML parsers used
by Tomcat to process XSLTs for the default servlet, JSP documents, tag
library descriptors (TLDs) and tag plugin configuration files. The
injected XMl parser(s) could then bypass the limits imposed on XML
external entities and/or have visibility of the XML files processed for
other web applications deployed on the same Tomcat instance.

2.5.2 Maintenance Release

The Hyperic tc Server plug-in version 2.5.2 is included in the
Hyperic 4.5.2.1 maintenance release. The tc Server plug-in is now Java
1.5 compatible as required by Hyperic.

tc Runtime Version Upgrades

tc Server 2.5.2 includes the following upgraded tc Runtime
versions:

tc Runtime 6.0 is based on Apache Tomcat 6.0.33

tc Runtime 7.0 is based on Apache Tomcat 7.0.20

2.5.1 Maintenance Release

tc Runtime 7.0 Version Update

The tc Runtime 7.0 version is based on
tomcat-7.0.16.A-RELEASE as its core.

New Option for Hyperic tc Server Command-Line create-group
Command

The Hyperic tc Server command-line interface
create-group command has a new --version
option to specify the tc Runtime version. The option accepts values of
6.0 and 7.0. Only servers of the specified tc
Runtime version can be added to a group.

2.5.0 Release

The 2.5.0 release of tc Server includes support for tc Runtimes
based on Tomcat 6.0 and Tomcat 7.0. You can choose the version of tc
Runtime when you create an instance. tc Runtime 7.0 offers several new
features, including support for the Servlet 3.0, JSP 2.2, and JSP-EL2.2
specifications, as well as security improvements.

Following are additional features and changes that are new to this
tc Server release:

When using tc Runtime 7.0, you can deploy multiple versions of
a web application with the same context path simultaneously by
appending a version number to the context name. This makes it
possible to deploy an updated application without interrupting
existing sessions. New requests for the application are routed to
the newest version of the application. Requests that have existing
session information continue to use the version of the application
that is managing the session. See Deploying Multiple Versions of an
Application in this guide. See The
Context Container at the Apache website for more details
about this feature.

The tcruntime-instance command has a new
upgrade verb that you can use to upgrade a tc Server
instance created with tc Server 2.0 or tc Server 2.1 to tc Server
2.5. You can specify the new tc Runtime version to use or allow the
upgraded instance to continue using the same tc Runtime version, if
that version is available in the new tc Server release.