Secure testing team - Oct 2008 - Bug#503309: tomcat6: Several security issues in Tomcat

Package: tomcat6
Severity: grave
Tags: security
Justification: user security hole

Several vulnerabilities have been fixed in Apache Tomcat 6.0.18, see
below.

BTW, do we really need two Tomcat versions in Lenny? Is Tomcat 6
incompatible with 5.5?

Cheers,
        Moritz

    low: Cross-site scripting CVE-2008-1232

    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.

    This was fixed in revision 673834.

    Affects: 6.0.0-6.0.16


    low: Cross-site scripting CVE-2008-1947

    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.

    This was fixed in revision 662585.

    Affects: 6.0.0-6.0.16


    important: Information disclosure CVE-2008-2370

    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.

    This was fixed in revision 673839.

    Affects: 6.0.0-6.0.16


    important: Directory traversal CVE-2008-2938

    If a context is configured with allowLinking="true" and the
connector is configured with URIEncoding="UTF-8" then a
+malformed request may be used to access arbitrary files on the server. If the
connector is configured with URIEncoding="UTF-8"
+then a malformed request may be used to access arbitrary files within the
docBase of a context such as web.xml. 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.

    This was fixed in revision 678137.

    Affects: 6.0.0-6.0.16



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, ''unstable'')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-15 at euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash