UbuntuUpdates.org

Package "tomcat9-user"

Name: tomcat9-user

Description:

Apache Tomcat 9 - Servlet and JSP engine -- tools to create user instances

Latest version: 9.0.31-1ubuntu0.8
Release: focal (20.04)
Level: updates
Repository: universe
Head package: tomcat9
Homepage: http://tomcat.apache.org

Links


Download "tomcat9-user"


Other versions of "tomcat9-user" in Focal

Repository Area Version
base universe 9.0.31-1
security universe 9.0.31-1ubuntu0.8

Changelog

Version: 9.0.31-1ubuntu0.3 2022-08-17 01:07:07 UTC

  tomcat9 (9.0.31-1ubuntu0.3) focal; urgency=medium

  * Fix logging for unprivileged rsyslogd (LP: #1964881):
    - d/logrotate.template: use syslog:adm for log rotation so that
      rsyslog can write to the file
    - d/tomcat9.postinst: adjust ownership of catalina.out so that
      rsyslogd can write to it. Also change the rotated log files for
      consistency.
    - d/tomcat9.tmpfile: /var/log/tomcat9 should be 02770 now

 -- Andreas Hasenack <email address hidden> Wed, 20 Jul 2022 15:09:00 -0300

Source diff to previous version
1964881 Logging/Log rotation does not work for catalina.out

Version: 9.0.31-1ubuntu0.2 2022-03-31 16:06:29 UTC

  tomcat9 (9.0.31-1ubuntu0.2) focal-security; urgency=medium

  * SECURITY UPDATE: TLS Denial of Service
    - debian/patches/CVE-2021-41079.patch: Apache Tomcat did not properly
      validate incoming TLS packets. When Tomcat was configured to use
      NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be
      used to trigger an infinite loop resulting in a denial of service.
    - CVE-2021-41079
  * SECURITY UPDATE: Authentication Vulnerability
    - debian/patches/CVE-2021-30640.patch: A vulnerability in the JNDI Realm
      of Apache Tomcat allows an attacker to authenticate using variations of
      a validc user name and/or to bypass some of the protection provided by
      the LockOut Realm.
    - CVE-2021-30640
  * SECURITY UPDATE: Request Smuggling
    - debian/patches/CVE-2021-33037.patch: Apache Tomcat did not correctly
      parse the HTTP transfer-encoding request header in some circumstances
      leading to the possibility to request smuggling when used with a reverse
      proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding
      header if the client declared it would only accept an HTTP/1.0 response;
      - Tomcat honoured the identify encoding; and - Tomcat did not ensure
      that, if present, the chunked encoding was the final encoding.
    - CVE-2021-33037
  * SECURITY UPDATE: remote code execution via session persistence
    - debian/patches/CVE-2021-25329.patch: The fix for CVE-2020-9484 was
      incomplete. When using Apache Tomcat with a configuration edge case that
      was highly unlikely to be used, the Tomcat instance was still vulnerable
      to CVE-2020-9494. Note that both the previously published prerequisites
      for CVE-2020-9484 and the previously published mitigations for
      CVE-2020-9484 also apply to this issue.
    - CVE-2021-25329
  * SECURITY UPDATE: Request Header Duplication
    - debian/patches/CVE-2021-25122.patch: When responding to new h2c
      connection requests, Apache Tomcat could duplicate request headers and a
      limited amount of request body from one request to another meaning user
      A and user B could both see the results of user A's request.
    - CVE-2021-25122
  * SECURITY UPDATE: HTTP/2 request header mix-up
    - debian/patches/CVE-2020-17527.patch: HTTP/2 It was discovered that
      Apache Tomcat could re-use an HTTP request header value from the previous
      stream received on an HTTP/2 connection for the request associated with
      the subsequent stream. While this would most likely lead to an error and
      the closure of the HTTP/2 connection, it is possible that information
      could leak between requests.
    - CVE-2020-17527
  * SECURITY UPDATE: HTTP/2 request mix-up
    - debian/patches/CVE-2020-13943.patch: If an HTTP/2 client exceeded the
      agreed maximum number of concurrent streams for a connection (in
      violation of the HTTP/2 protocol), it was possible that a subsequent
      request made on that connection could contain HTTP headers - including
      HTTP/2 pseudo headers - from a previous request rather than the intended
      headers. This could lead to users seeing responses for unexpected
      resources.
    - CVE-2020-13943

 -- Evren Yurtesen <email address hidden> Wed, 16 Mar 2022 20:51:24 +0200

Source diff to previous version
CVE-2021-41079 Apache Tomcat 8.5.0 to 8.5.63, 9.0.0-M1 to 9.0.43 and 10.0.0-M1 to 10.0.2 did not properly validate incoming TLS packets. When Tomcat was configured
CVE-2021-30640 A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker to authenticate using variations of a valid user name and/or to bypass some of
CVE-2021-33037 Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some c
CVE-2021-25329 The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with
CVE-2020-9484 When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to contr
CVE-2020-9494 Apache Traffic Server 6.0.0 to 6.2.3, 7.0.0 to 7.1.10, and 8.0.0 to 8.0.7 is vulnerable to certain types of HTTP/2 HEADERS frames that can cause the
CVE-2021-25122 When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate re
CVE-2020-17527 While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTT
CVE-2020-13943 If an HTTP/2 client connecting to Apache Tomcat 10.0.0-M1 to 10.0.0-M7, 9.0.0.M1 to 9.0.37 or 8.5.0 to 8.5.57 exceeded the agreed maximum number of c

Version: 9.0.31-1ubuntu0.1 2020-10-21 15:06:26 UTC

  tomcat9 (9.0.31-1ubuntu0.1) focal-security; urgency=medium

  * SECURITY UPDATE: HTTP/2 Denial of Service
    - debian/patches/CVE-2020-13934.patch: ensure that the HTTP/1.1
      processor is correctly recycled when a direct connection to h2c is
      made
    - CVE-2020-13934
  * SECURITY UPDATE: WebSocket Denial of Service
    - debian/patches/CVE-2020-13935.patch: add additional validation of
      payload length for WebSocket messages
    - CVE-2020-13935
  * SECURITY UPDATE: HTTP/2 Denial of Service
    - debian/patches/CVE-2020-11996.patch: improve performance of closing
      idle HTTP/2 streams
    - CVE-2020-11996
  * SECURITY UPDATE: remote code execution via session persistence
    - debian/patches/CVE-2020-9484.patch: improve validation of storage
      location when using FileStore
    - CVE-2020-9484

 -- Emilia Torino <email address hidden> Tue, 20 Oct 2020 09:27:39 -0300

CVE-2020-13934 An h2c direct connection to Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56 did not release the HTTP/1.1 processor after
CVE-2020-13935 The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and
CVE-2020-11996 A specially crafted sequence of HTTP/2 requests sent to Apache Tomcat 10.0.0-M1 to 10.0.0-M5, 9.0.0.M1 to 9.0.35 and 8.5.0 to 8.5.55 could trigger hi
CVE-2020-9484 When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to contr



About   -   Send Feedback to @ubuntu_updates