From owner-freebsd-security@freebsd.org Wed Jun 22 13:20:07 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00E36AC5285 for ; Wed, 22 Jun 2016 13:20:07 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC3902F66 for ; Wed, 22 Jun 2016 13:20:06 +0000 (UTC) (envelope-from marquis@roble.com) Date: Wed, 22 Jun 2016 06:15:29 -0700 (PDT) From: Roger Marquis To: freebsd-security@freebsd.org Subject: Re: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 13:20:07 -0000 These vulnerabilities seem to be missing from the current vuln.xml, FYI. Roger >Date: Wed, 22 Jun 2016 11:02:59 +0100 >From: Mark Thomas >Reply-To: announce@tomcat.apache.org >To: "users@tomcat.apache.org" >Cc: "dev@tomcat.apache.org" , > "announce@tomcat.apache.org" , > announce@apache.org >Subject: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service > >Note: This announcement corrects several errors and omissions in the >Tomcat aspects of the announcement for CVE-2016-3092 from the Apache >Commons project that was recently forwarded to various Apache Tomcat >mailing lists. > >For the sake of clarity, the Tomcat specific corrections are as follows: >1. This is a Denial of Service vulnerability, not an Information >Disclosure vulnerability. >2. Apache Tomcat 8.5.x is also affected. The vulnerability exists in >8.5.0 to 8.5.2 and affected users of 8.5.x should upgrade to 8.5.3. >3. Apache Tomcat 6.x and earlier are not affected. >4. Applications that do not use the File Upload feature introduced in >Servlet 3.0 are not vulnerable via Tomcat. > >A corrected announcement, for Tomcat only, follows. > > >CVE-2016-3092: Apache Tomcat Denial of Service > >Severity: Moderate > >Vendor: >The Apache Software Foundation > >Versions Affected: >Apache Tomcat 9.0.0.M1 to 9.0.0M6 >Apache Tomcat 8.5.0 to 8.5.2 >Apache Tomcat 8.0.0.RC1 to 8.0.35 >Apache Tomcat 7.0.0 to 7.0.69 >Earlier versions are not affected. > >Description: >CVE-2016-3092 is a denial of service vulnerability that has been >corrected in the Apache Commons FileUpload component. It occurred when >the length of the multipart boundary was just below the size of the >buffer (4096 bytes) used to read the uploaded file. This caused the file >upload process to take several orders of magnitude longer than if the >boundary length was the typical tens of bytes. > >Apache Tomcat uses a package renamed copy of Apache Commons FileUpload >to implement the file upload requirements of the Servlet specification >and was therefore also vulnerable to the denial of service vulnerability. > >Applications that do not use the File Upload feature introduced in >Servlet 3.0 are not affected by the Tomcat aspect of this vulnerability. >If those applications use Apache Commons FileUpload, they may still be >affected. > >Mitigation: >Users of affected versions should apply one of the following mitigations >- Upgrade to Apache Tomcat 9.0.0.M8 or later > (9.0.0.M7 has the fix but was not released) >- Upgrade to Apache Tomcat 8.5.3 or later >- Upgrade to Apache Tomcat 8.0.36 or later >- Upgrade to Apache Tomcat 7.0.70 or later > >Workaround: >The issue may be mitigated by limiting the length of the boundary. >Applications could do this with a custom Filter to reject requests that >use large boundaries. >Tomcat provides the maxHttpHeaderSize attribute on the Connector that >can be used to limit the total HTTP header size. Users should be aware >that reducing this to 3072 (which should be low enough to protect >against this DoS) may cause other issues as applications can require >larger headers than this for correct operation, particularly if the >application uses relatively large cookie values. > >Credit: >This issue was identified by the TERASOLUNA Framework Development Team >at the Software Engineering, Research and Development Headquarters and >reported to the ASF via JPCERT. > >References: >http://tomcat.apache.org/security-9.html >http://tomcat.apache.org/security-8.html >http://tomcat.apache.org/security-7.html