Author: markt
Date: Tue Jun 6 10:21:52 2017
New Revision: 1797770
URL: http://svn.apache.org/viewvc?rev=1797770&view=rev
Log:
Add CVE-2017-5664
Modified:
tomcat/site/trunk/docs/security-7.html
tomcat/site/trunk/docs/security-8.html
tomcat/site/trunk/docs/security-9.html
tomcat/site/trunk/xdocs/security-7.xml
tomcat/site/trunk/xdocs/security-8.xml
tomcat/site/trunk/xdocs/security-9.xml
Modified: tomcat/site/trunk/docs/security-7.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-7.html?rev=1797770&r1=1797769&r2=1797770&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-7.html (original)
+++ tomcat/site/trunk/docs/security-7.html Tue Jun 6 10:21:52 2017
@@ -227,6 +227,9 @@
<a href="#Apache_Tomcat_7.x_vulnerabilities">Apache Tomcat 7.x
vulnerabilities</a>
</li>
<li>
+<a href="#Fixed_in_Apache_Tomcat_7.0.78">Fixed in Apache Tomcat 7.0.78</a>
+</li>
+<li>
<a href="#Fixed_in_Apache_Tomcat_7.0.77">Fixed in Apache Tomcat 7.0.77</a>
</li>
<li>
@@ -380,6 +383,64 @@
</div>
+<h3 id="Fixed_in_Apache_Tomcat_7.0.78">
+<span style="float: right;">16 May 2017</span> Fixed in Apache Tomcat
7.0.78</h3>
+<div class="text">
+
+
+<p>
+<strong>Important: Security Constraint Bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664";
rel="nofollow">CVE-2017-5664</a>
+</p>
+
+
+<p>The error page mechanism of the Java Servlet Specification requires that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+
+<p>If the error page is a static file, expected behaviour is to serve content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+
+<p>Notes for other user provided error pages:</p>
+
+<ul>
+
+<li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+
+<li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+
+</ul>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793471";>1793471</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793491";>1793491</a>.</p>
+
+
+<p>This issue was reported responsibly to the Apache Tomcat Security Team by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+
+<p>Affects: 7.0.0 to 7.0.77</p>
+
+
+</div>
<h3 id="Fixed_in_Apache_Tomcat_7.0.77">
<span style="float: right;">2 April 2017</span> Fixed in Apache Tomcat
7.0.77</h3>
<div class="text">
Modified: tomcat/site/trunk/docs/security-8.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-8.html?rev=1797770&r1=1797769&r2=1797770&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-8.html (original)
+++ tomcat/site/trunk/docs/security-8.html Tue Jun 6 10:21:52 2017
@@ -227,6 +227,12 @@
<a href="#Apache_Tomcat_8.x_vulnerabilities">Apache Tomcat 8.x
vulnerabilities</a>
</li>
<li>
+<a href="#Fixed_in_Apache_Tomcat_8.0.44">Fixed in Apache Tomcat 8.0.44</a>
+</li>
+<li>
+<a href="#Fixed_in_Apache_Tomcat_8.5.15">Fixed in Apache Tomcat 8.5.15</a>
+</li>
+<li>
<a href="#Fixed_in_Apache_Tomcat_8.0.43">Fixed in Apache Tomcat 8.0.43</a>
</li>
<li>
@@ -341,6 +347,122 @@
</div>
+<h3 id="Fixed_in_Apache_Tomcat_8.0.44">
+<span style="float: right;">16 May 2017</span> Fixed in Apache Tomcat
8.0.44</h3>
+<div class="text">
+
+
+<p>
+<strong>Important: Security Constraint Bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664";
rel="nofollow">CVE-2017-5664</a>
+</p>
+
+
+<p>The error page mechanism of the Java Servlet Specification requires that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+
+<p>If the error page is a static file, expected behaviour is to serve content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+
+<p>Notes for other user provided error pages:</p>
+
+<ul>
+
+<li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+
+<li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+
+</ul>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793470";>1793470</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793489";>1793489</a>.</p>
+
+
+<p>This issue was reported responsibly to the Apache Tomcat Security Team by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.43</p>
+
+
+</div>
+<h3 id="Fixed_in_Apache_Tomcat_8.5.15">
+<span style="float: right;">10 May 2017</span> Fixed in Apache Tomcat
8.5.15</h3>
+<div class="text">
+
+
+<p>
+<strong>Important: Security Constraint Bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664";
rel="nofollow">CVE-2017-5664</a>
+</p>
+
+
+<p>The error page mechanism of the Java Servlet Specification requires that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+
+<p>If the error page is a static file, expected behaviour is to serve content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+
+<p>Notes for other user provided error pages:</p>
+
+<ul>
+
+<li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+
+<li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+
+</ul>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793469";>1793469</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793488";>1793488</a>.</p>
+
+
+<p>This issue was reported responsibly to the Apache Tomcat Security Team by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+
+<p>Affects: 8.5.0 to 8.5.14</p>
+
+
+</div>
<h3 id="Fixed_in_Apache_Tomcat_8.0.43">
<span style="float: right;">2 April 2017</span> Fixed in Apache Tomcat
8.0.43</h3>
<div class="text">
Modified: tomcat/site/trunk/docs/security-9.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-9.html?rev=1797770&r1=1797769&r2=1797770&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-9.html (original)
+++ tomcat/site/trunk/docs/security-9.html Tue Jun 6 10:21:52 2017
@@ -227,6 +227,9 @@
<a href="#Apache_Tomcat_9.x_vulnerabilities">Apache Tomcat 9.x
vulnerabilities</a>
</li>
<li>
+<a href="#Fixed_in_Apache_Tomcat_9.0.0.M21">Fixed in Apache Tomcat
9.0.0.M21</a>
+</li>
+<li>
<a href="#Fixed_in_Apache_Tomcat_9.0.0.M19">Fixed in Apache Tomcat
9.0.0.M19</a>
</li>
<li>
@@ -299,6 +302,64 @@
</div>
+<h3 id="Fixed_in_Apache_Tomcat_9.0.0.M21">
+<span style="float: right;">10 May 2017</span> Fixed in Apache Tomcat
9.0.0.M21</h3>
+<div class="text">
+
+
+<p>
+<strong>Important: Security Constraint Bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664";
rel="nofollow">CVE-2017-5664</a>
+</p>
+
+
+<p>The error page mechanism of the Java Servlet Specification requires that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+
+<p>If the error page is a static file, expected behaviour is to serve content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+
+<p>Notes for other user provided error pages:</p>
+
+<ul>
+
+<li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+
+<li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+
+</ul>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793468";>1793468</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1793487";>1793487</a>.</p>
+
+
+<p>This issue was reported responsibly to the Apache Tomcat Security Team by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+
+<p>Affects: 9.0.0.M1 to 9.0.0.M20</p>
+
+
+</div>
<h3 id="Fixed_in_Apache_Tomcat_9.0.0.M19">
<span style="float: right;">30 March 2017</span> Fixed in Apache Tomcat
9.0.0.M19</h3>
<div class="text">
Modified: tomcat/site/trunk/xdocs/security-7.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-7.xml?rev=1797770&r1=1797769&r2=1797770&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-7.xml (original)
+++ tomcat/site/trunk/xdocs/security-7.xml Tue Jun 6 10:21:52 2017
@@ -50,6 +50,49 @@
</section>
+ <section name="Fixed in Apache Tomcat 7.0.78" rtext="16 May 2017">
+
+ <p><strong>Important: Security Constraint Bypass</strong>
+ <cve>CVE-2017-5664</cve></p>
+
+ <p>The error page mechanism of the Java Servlet Specification requires
that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+ <p>If the error page is a static file, expected behaviour is to serve
content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+ <p>Notes for other user provided error pages:</p>
+ <ul>
+ <li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+ <li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+ </ul>
+
+ <p>This was fixed in revisions <revlink rev="1793471">1793471</revlink> and
+ <revlink rev="1793491">1793491</revlink>.</p>
+
+ <p>This issue was reported responsibly to the Apache Tomcat Security Team
by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+ <p>Affects: 7.0.0 to 7.0.77</p>
+
+ </section>
+
<section name="Fixed in Apache Tomcat 7.0.77" rtext="2 April 2017">
<p><strong>Important: Information Disclosure</strong>
Modified: tomcat/site/trunk/xdocs/security-8.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-8.xml?rev=1797770&r1=1797769&r2=1797770&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-8.xml (original)
+++ tomcat/site/trunk/xdocs/security-8.xml Tue Jun 6 10:21:52 2017
@@ -50,6 +50,92 @@
</section>
+ <section name="Fixed in Apache Tomcat 8.0.44" rtext="16 May 2017">
+
+ <p><strong>Important: Security Constraint Bypass</strong>
+ <cve>CVE-2017-5664</cve></p>
+
+ <p>The error page mechanism of the Java Servlet Specification requires
that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+ <p>If the error page is a static file, expected behaviour is to serve
content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+ <p>Notes for other user provided error pages:</p>
+ <ul>
+ <li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+ <li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+ </ul>
+
+ <p>This was fixed in revisions <revlink rev="1793470">1793470</revlink> and
+ <revlink rev="1793489">1793489</revlink>.</p>
+
+ <p>This issue was reported responsibly to the Apache Tomcat Security Team
by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.43</p>
+
+ </section>
+
+ <section name="Fixed in Apache Tomcat 8.5.15" rtext="10 May 2017">
+
+ <p><strong>Important: Security Constraint Bypass</strong>
+ <cve>CVE-2017-5664</cve></p>
+
+ <p>The error page mechanism of the Java Servlet Specification requires
that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+ <p>If the error page is a static file, expected behaviour is to serve
content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+ <p>Notes for other user provided error pages:</p>
+ <ul>
+ <li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+ <li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+ </ul>
+
+ <p>This was fixed in revisions <revlink rev="1793469">1793469</revlink> and
+ <revlink rev="1793488">1793488</revlink>.</p>
+
+ <p>This issue was reported responsibly to the Apache Tomcat Security Team
by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+ <p>Affects: 8.5.0 to 8.5.14</p>
+
+ </section>
+
<section name="Fixed in Apache Tomcat 8.0.43" rtext="2 April 2017">
<p><strong>Important: Information Disclosure</strong>
Modified: tomcat/site/trunk/xdocs/security-9.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-9.xml?rev=1797770&r1=1797769&r2=1797770&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-9.xml (original)
+++ tomcat/site/trunk/xdocs/security-9.xml Tue Jun 6 10:21:52 2017
@@ -50,6 +50,49 @@
</section>
+ <section name="Fixed in Apache Tomcat 9.0.0.M21" rtext="10 May 2017">
+
+ <p><strong>Important: Security Constraint Bypass</strong>
+ <cve>CVE-2017-5664</cve></p>
+
+ <p>The error page mechanism of the Java Servlet Specification requires
that,
+ when an error occurs and an error page is configured for the error that
+ occurred, the original request and response are forwarded to the error
+ page. This means that the request is presented to the error page with
the
+ original HTTP method.</p>
+
+ <p>If the error page is a static file, expected behaviour is to serve
content
+ of the file as if processing a GET request, regardless of the actual HTT
+ method. Tomcat's Default Servlet did not do this. Depending on the
+ original request this could lead to unexpected and undesirable results
for
+ static error pages including, if the DefaultServlet is configured to
+ permit writes, the replacement or removal of the custom error page.</p>
+
+ <p>Notes for other user provided error pages:</p>
+ <ul>
+ <li>Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
+ JSPs used as error pages must must ensure that they handle any error
+ dispatch as a GET request, regardless of the actual method.</li>
+ <li>By default, the response generated by a Servlet does depend on the
+ HTTP method. Custom Servlets used as error pages must ensure that
+ they handle any error dispatch as a GET request, regardless of the
+ actual method.</li>
+ </ul>
+
+ <p>This was fixed in revisions <revlink rev="1793468">1793468</revlink> and
+ <revlink rev="1793487">1793487</revlink>.</p>
+
+ <p>This issue was reported responsibly to the Apache Tomcat Security Team
by
+ Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai,
+ India as a vulnerability that allowed the restrictions on OPTIONS and
+ TRACE requests to be bypassed on 21 April 2017. The full implications of
+ this issue were identified by the Tomcat Security Team on 24 April 2017.
+ This issue was made public on 6 June 2017.</p>
+
+ <p>Affects: 9.0.0.M1 to 9.0.0.M20</p>
+
+ </section>
+
<section name="Fixed in Apache Tomcat 9.0.0.M19" rtext="30 March 2017">
<p><strong>Important: Information Disclosure</strong>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
