Author: markt
Date: Mon Feb 22 11:21:42 2016
New Revision: 1731626
URL: http://svn.apache.org/viewvc?rev=1731626&view=rev
Log:
Announcements for 7 CVEs
Modified:
tomcat/site/trunk/docs/index.html
tomcat/site/trunk/docs/security-6.html
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-6.xml
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/index.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/index.html?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/docs/index.html (original)
+++ tomcat/site/trunk/docs/index.html Mon Feb 22 11:21:42 2016
@@ -254,7 +254,8 @@ include:
<ul>
<li>Restore the default for mapperContextRootRedirectEnabled to
- <code>true</code></li>
+ <code>true</code>
+</li>
<li>Expand session attribute filtering on load/unload to all managers</li>
Modified: tomcat/site/trunk/docs/security-6.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-6.html (original)
+++ tomcat/site/trunk/docs/security-6.html Mon Feb 22 11:21:42 2016
@@ -215,6 +215,9 @@
<a href="#Apache_Tomcat_6.x_vulnerabilities">Apache Tomcat 6.x
vulnerabilities</a>
</li>
<li>
+<a href="#Fixed_in_Apache_Tomcat_6.0.45">Fixed in Apache Tomcat 6.0.45</a>
+</li>
+<li>
<a href="#Fixed_in_Apache_Tomcat_6.0.44">Fixed in Apache Tomcat 6.0.44</a>
</li>
<li>
@@ -324,6 +327,137 @@
</div>
+<h3 id="Fixed_in_Apache_Tomcat_6.0.45">
+<span style="float: right;">11 February 2016</span> Fixed in Apache Tomcat
6.0.45</h3>
+<div class="text">
+
+
+<p>
+<strong>Low: Limited directory traversal</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5174";
rel="nofollow">CVE-2015-5174</a>
+</p>
+
+
+<p>When accessing resources via the <code>ServletContext</code> methods
+ <code>getResource()</code> <code>getResourceAsStream()</code> and
+ <code>getResourcePaths()</code> the paths should be limited to the
+ current web application. The validation was not correct and paths of the
+ form <code>"/.."</code> were not rejected. Note that paths starting with
+ <code>"/../"</code> were correctly rejected. This bug allowed malicious
+ web applications running under a security manager to obtain a directory
+ listing for the directory in which the web application had been
deployed.
+ This should not be possible when running under a security manager.
+ Typically, the directory listing that would be exposed would be for
+ <code>$CATALINA_BASE/webapps.</code>
+</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1700900";>1700900</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 August 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 6.0.0 to 6.0.44</p>
+
+
+<p>
+<strong>Low: Directory disclosure</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5345";
rel="nofollow">CVE-2015-5345</a>
+</p>
+
+
+<p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+
+<p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1715216";>1715216</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1717216";>1717216</a>.</p>
+
+
+<p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+
+<p>Affects: 6.0.0 to 6.0.44</p>
+
+
+<p>
+<strong>Low: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0706";
rel="nofollow">CVE-2016-0706</a>
+</p>
+
+
+<p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1722802";>1722802</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 27 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 6.0.0 to 6.0.44</p>
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0714";
rel="nofollow">CVE-2016-0714</a>
+</p>
+
+
+<p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1727166";>1727166</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1727182";>1727182</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 November 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 6.0.0 to 6.0.44</p>
+
+
+</div>
<h3 id="Fixed_in_Apache_Tomcat_6.0.44">
<span style="float: right;">12 May 2015</span> Fixed in Apache Tomcat
6.0.44</h3>
<div class="text">
Modified: tomcat/site/trunk/docs/security-7.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-7.html?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-7.html (original)
+++ tomcat/site/trunk/docs/security-7.html Mon Feb 22 11:21:42 2016
@@ -215,6 +215,15 @@
<a href="#Apache_Tomcat_7.x_vulnerabilities">Apache Tomcat 7.x
vulnerabilities</a>
</li>
<li>
+<a href="#Fixed_in_Apache_Tomcat_7.0.68">Fixed in Apache Tomcat 7.0.68</a>
+</li>
+<li>
+<a href="#Fixed_in_Apache_Tomcat_7.0.67">Fixed in Apache Tomcat 7.0.67</a>
+</li>
+<li>
+<a href="#Fixed_in_Apache_Tomcat_7.0.65">Fixed in Apache Tomcat 7.0.65</a>
+</li>
+<li>
<a href="#Fixed_in_Apache_Tomcat_7.0.59">Fixed in Apache Tomcat 7.0.59</a>
</li>
<li>
@@ -341,6 +350,235 @@
</div>
+<h3 id="Fixed_in_Apache_Tomcat_7.0.68">
+<span style="float: right;">16 February 2016</span> Fixed in Apache Tomcat
7.0.68</h3>
+<div class="text">
+
+
+<p>
+<strong>Low: CSRF token leak</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5351";
rel="nofollow">CVE-2015-5351</a>
+</p>
+
+
+<p>The index page of the Manager and Host Manager applications included a
+ valid CSRF token when issuing a redirect as a result of an
+ unauthenticated request to the root of the web application. This token
+ could then be used by an attacker to construct a CSRF attack.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1720661";>1720661</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1720663";>1720663</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 8 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.1 to 7.0.67</p>
+
+
+<p>
+<strong>Low: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0706";
rel="nofollow">CVE-2016-0706</a>
+</p>
+
+
+<p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1722801";>1722801</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 27 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.0 to 7.0.67</p>
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0714";
rel="nofollow">CVE-2016-0714</a>
+</p>
+
+
+<p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1726923";>1726923</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1727034";>1727034</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 November 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.0 to 7.0.67</p>
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0763";
rel="nofollow">CVE-2016-0763</a>
+</p>
+
+
+<p>
+<code>ResourceLinkFactory.setGlobalContext()</code> is a public method
+ and was accessible by web applications running under a security manager
+ without any checks. This allowed a malicious web application to inject a
+ malicious global context that could in turn be used to disrupt other web
+ applications and/or read and write data owned by other web
+ applications.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1725931";>1725931</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 18 January 2016
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.0 to 7.0.67</p>
+
+
+</div>
+<h3 id="Fixed_in_Apache_Tomcat_7.0.67">
+<span style="float: right;">10 December 2015</span> Fixed in Apache Tomcat
7.0.67</h3>
+<div class="text">
+
+
+<p>
+<strong>Low: Directory disclosure</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5345";
rel="nofollow">CVE-2015-5345</a>
+</p>
+
+
+<p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+
+<p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1715213";>1715213</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1717212";>1717212</a>.</p>
+
+
+<p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.0 to 7.0.66</p>
+
+
+<p>
+<i>Note: The issue below was fixed in Apache Tomcat 7.0.66 but the
+ release vote for the 7.0.66 release candidate did not pass. Therefore,
+ although users must download 7.0.67 to obtain a version that includes a
+ fix for this issue, version 7.0.66 is not included in the list of
+ affected versions.</i>
+</p>
+
+
+<p>
+<strong>Low: Session Fixation</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5346";
rel="nofollow">CVE-2015-5346</a>
+</p>
+
+
+<p>When recycling the <code>Request</code> object to use for a new request,
+ the <code>requestedSessionSSL</code> field was not recycled. This meant
that
+ a session ID provided in the next request to be processed using the
recycled
+ <code>Request</code> object could be used when it should not have been.
This
+ gave the client the ability to control the session ID. In theory, this
could
+ have been used as part of a session fixation attack but it would have been
+ hard to achieve as the attacker would not have been able to force the
victim
+ to use the 'correct' <code>Request</code> object. It was also necessary for
+ at least one web application to be configured to use the SSL session ID as
+ the HTTP session ID. This is not a common configuration.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1713187";>1713187</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 22 June 2014
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.5 to 7.0.65</p>
+
+
+</div>
+<h3 id="Fixed_in_Apache_Tomcat_7.0.65">
+<span style="float: right;">19 October 2015</span> Fixed in Apache Tomcat
7.0.65</h3>
+<div class="text">
+
+
+<p>
+<strong>Low: Limited directory traversal</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5174";
rel="nofollow">CVE-2015-5174</a>
+</p>
+
+
+<p>When accessing resources via the <code>ServletContext</code> methods
+ <code>getResource()</code> <code>getResourceAsStream()</code> and
+ <code>getResourcePaths()</code> the paths should be limited to the
+ current web application. The validation was not correct and paths of the
+ form <code>"/.."</code> were not rejected. Note that paths starting with
+ <code>"/../"</code> were correctly rejected. This bug allowed malicious
+ web applications running under a security manager to obtain a directory
+ listing for the directory in which the web application had been
deployed.
+ This should not be possible when running under a security manager.
+ Typically, the directory listing that would be exposed would be for
+ <code>$CATALINA_BASE/webapps.</code>
+</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1696284";>1696284</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1700898";>1700898</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 August 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 7.0.0 to 7.0.64</p>
+
+
+</div>
<h3 id="Fixed_in_Apache_Tomcat_7.0.59">
<span style="float: right;">4 February 2015</span> Fixed in Apache Tomcat
7.0.59</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=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-8.html (original)
+++ tomcat/site/trunk/docs/security-8.html Mon Feb 22 11:21:42 2016
@@ -215,6 +215,15 @@
<a href="#Apache_Tomcat_8.x_vulnerabilities">Apache Tomcat 8.x
vulnerabilities</a>
</li>
<li>
+<a href="#Fixed_in_Apache_Tomcat_8.0.32">Fixed in Apache Tomcat 8.0.32</a>
+</li>
+<li>
+<a href="#Fixed_in_Apache_Tomcat_8.0.30">Fixed in Apache Tomcat 8.0.30</a>
+</li>
+<li>
+<a href="#Fixed_in_Apache_Tomcat_8.0.27">Fixed in Apache Tomcat 8.0.27</a>
+</li>
+<li>
<a href="#Fixed_in_Apache_Tomcat_8.0.17">Fixed in Apache Tomcat 8.0.17</a>
</li>
<li>
@@ -287,6 +296,236 @@
</div>
+<h3 id="Fixed_in_Apache_Tomcat_8.0.32">
+<span style="float: right;">8 February 2016</span> Fixed in Apache Tomcat
8.0.32</h3>
+<div class="text">
+
+
+<p>
+<i>Note: The issues below were fixed in Apache Tomcat 8.0.31 but the
+ release vote for the 8.0.31 release candidate did not pass. Therefore,
+ although users must download 8.0.32 to obtain a version that includes
+ fixes for these issues, version 8.0.31 is not included in the list of
+ affected versions.</i>
+</p>
+
+
+<p>
+<strong>Low: Session Fixation</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5346";
rel="nofollow">CVE-2015-5346</a>
+</p>
+
+
+<p>When recycling the <code>Request</code> object to use for a new request,
+ the <code>requestedSessionSSL</code> field was not recycled. This meant
that
+ a session ID provided in the next request to be processed using the
recycled
+ <code>Request</code> object could be used when it should not have been.
This
+ gave the client the ability to control the session ID. In theory, this
could
+ have been used as part of a session fixation attack but it would have been
+ hard to achieve as the attacker would not have been able to force the
victim
+ to use the 'correct' <code>Request</code> object. It was also necessary for
+ at least one web application to be configured to use the SSL session ID as
+ the HTTP session ID. This is not a common configuration.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1713185";>1713185</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1723506";>1723506</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 22 June 2014
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+
+<p>
+<strong>Low: CSRF token leak</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5351";
rel="nofollow">CVE-2015-5351</a>
+</p>
+
+
+<p>The index page of the Manager and Host Manager applications included a
+ valid CSRF token when issuing a redirect as a result of an
+ unauthenticated request to the root of the web application. This token
+ could then be used by an attacker to construct a CSRF attack.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1720658";>1720658</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1720660";>1720660</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 8 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+
+<p>
+<strong>Low: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0706";
rel="nofollow">CVE-2016-0706</a>
+</p>
+
+
+<p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1722800";>1722800</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 27 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0714";
rel="nofollow">CVE-2016-0714</a>
+</p>
+
+
+<p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1726196";>1726196</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1726203";>1726203</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 November 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0763";
rel="nofollow">CVE-2016-0763</a>
+</p>
+
+
+<p>
+<code>ResourceLinkFactory.setGlobalContext()</code> is a public method
+ and was accessible by web applications running under a security manager
+ without any checks. This allowed a malicious web application to inject a
+ malicious global context that could in turn be used to disrupt other web
+ applications and/or read and write data owned by other web
+ applications.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1725929";>1725929</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 18 January 2016
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+
+</div>
+<h3 id="Fixed_in_Apache_Tomcat_8.0.30">
+<span style="float: right;">6 December 2015</span> Fixed in Apache Tomcat
8.0.30</h3>
+<div class="text">
+
+
+<p>
+<strong>Low: Directory disclosure</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5345";
rel="nofollow">CVE-2015-5345</a>
+</p>
+
+
+<p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+
+<p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1715207";>1715207</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1717209";>1717209</a>.</p>
+
+
+<p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0.RC1 to 8.0.29</p>
+
+
+</div>
+<h3 id="Fixed_in_Apache_Tomcat_8.0.27">
+<span style="float: right;">1 October 2015</span> Fixed in Apache Tomcat
8.0.27</h3>
+<div class="text">
+
+
+<p>
+<strong>Low: Limited directory traversal</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5174";
rel="nofollow">CVE-2015-5174</a>
+</p>
+
+
+<p>When accessing resources via the <code>ServletContext</code> methods
+ <code>getResource()</code> <code>getResourceAsStream()</code> and
+ <code>getResourcePaths()</code> the paths should be limited to the
+ current web application. The validation was not correct and paths of the
+ form <code>"/.."</code> were not rejected. Note that paths starting with
+ <code>"/../"</code> were correctly rejected. This bug allowed malicious
+ web applications running under a security manager to obtain a directory
+ listing for the directory in which the web application had been
deployed.
+ This should not be possible when running under a security manager.
+ Typically, the directory listing that would be exposed would be for
+ <code>$CATALINA_BASE/webapps.</code>
+</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1696281";>1696281</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1700897";>1700897</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 August 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 8.0.0-RC1 to 8.0.26</p>
+
+
+</div>
<h3 id="Fixed_in_Apache_Tomcat_8.0.17">
<span style="float: right;">16 January 2015</span> Fixed in Apache Tomcat
8.0.17</h3>
<div class="text">
@@ -296,7 +535,7 @@
<i>Note: The issue below was fixed in Apache Tomcat 8.0.16 but the
release vote for the 8.0.16 release candidate did not pass. Therefore,
although users must download 8.0.17 to obtain a version that includes a
- fix for this issue, versions 8.0.16 is not included in the list of
+ fix for this issue, version 8.0.16 is not included in the list of
affected versions.</i>
</p>
Modified: tomcat/site/trunk/docs/security-9.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-9.html?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/docs/security-9.html (original)
+++ tomcat/site/trunk/docs/security-9.html Mon Feb 22 11:21:42 2016
@@ -215,7 +215,7 @@
<a href="#Apache_Tomcat_9.x_vulnerabilities">Apache Tomcat 9.x
vulnerabilities</a>
</li>
<li>
-<a href="#Fixed_in_Apache_Tomcat_9.0.x">Fixed in Apache Tomcat 9.0.x</a>
+<a href="#Fixed_in_Apache_Tomcat_9.0.0.M3">Fixed in Apache Tomcat 9.0.0.M3</a>
</li>
</ul>
@@ -266,11 +266,192 @@
</div>
-<h3 id="Fixed_in_Apache_Tomcat_9.0.x">Fixed in Apache Tomcat 9.0.x</h3>
+<h3 id="Fixed_in_Apache_Tomcat_9.0.0.M3">
+<span style="float: right;">5 January 2016</span> Fixed in Apache Tomcat
9.0.0.M3</h3>
<div class="text">
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0763";
rel="nofollow">CVE-2016-0763</a>
+</p>
+
+
+<p>
+<code>ResourceLinkFactory.setGlobalContext()</code> is a public method
+ and was accessible by web applications running under a security manager
+ without any checks. This allowed a malicious web application to inject a
+ malicious global context that could in turn be used to disrupt other web
+ applications and/or read and write data owned by other web
+ applications.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1725926";>1725926</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 18 January 2016
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 9.0.0.M1 to 9.0.0.M2</p>
+
+
+<p>
+<i>Note: The issues below were fixed in Apache Tomcat 9.0.0.M2 but the
+ release vote for the 9.0.0.M2 release candidate did not pass. Therefore,
+ although users must download 9.0.0.M3 to obtain a version that includes
+ fixes for these issues, version 9.0.0.M2 is not included in the list of
+ affected versions.</i>
+</p>
+
+
+<p>
+<strong>Low: Directory disclosure</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5345";
rel="nofollow">CVE-2015-5345</a>
+</p>
+
+
+<p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+
+<p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1715206";>1715206</a>,
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1716882";>1716882</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1716894";>1716894</a>.</p>
+
+
+<p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+
+<p>Affects: 9.0.0.M1</p>
+
+
+<p>
+<strong>Low: Session Fixation</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5346";
rel="nofollow">CVE-2015-5346</a>
+</p>
+
+
+<p>When recycling the <code>Request</code> object to use for a new request,
+ the <code>requestedSessionSSL</code> field was not recycled. This meant
that
+ a session ID provided in the next request to be processed using the
recycled
+ <code>Request</code> object could be used when it should not have been.
This
+ gave the client the ability to control the session ID. In theory, this
could
+ have been used as part of a session fixation attack but it would have been
+ hard to achieve as the attacker would not have been able to force the
victim
+ to use the 'correct' <code>Request</code> object. It was also necessary for
+ at least one web application to be configured to use the SSL session ID as
+ the HTTP session ID. This is not a common configuration.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1713184";>1713184</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1723414";>1723414</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 22 June 2014
+ and made public on 22 February 2016.</p>
-<p>There are currently no known vulnerabilities for Apache Tomcat 9.0.x</p>
+<p>Affects: 9.0.0.M1</p>
+
+
+<p>
+<strong>Low: CSRF token leak</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5351";
rel="nofollow">CVE-2015-5351</a>
+</p>
+
+
+<p>The index page of the Manager and Host Manager applications included a
+ valid CSRF token when issuing a redirect as a result of an
+ unauthenticated request to the root of the web application. This token
+ could then be used by an attacker to construct a CSRF attack.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1720652";>1720652</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1720655";>1720655</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 8 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 9.0.0.M1</p>
+
+
+<p>
+<strong>Low: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0706";
rel="nofollow">CVE-2016-0706</a>
+</p>
+
+
+<p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+
+<p>This was fixed in revision <a
href="http://svn.apache.org/viewvc?view=rev&rev=1722799";>1722799</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 27 December 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 9.0.0.M1</p>
+
+
+<p>
+<strong>Moderate: Security Manager bypass</strong>
+ <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0714";
rel="nofollow">CVE-2016-0714</a>
+</p>
+
+
+<p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+
+<p>This was fixed in revisions <a
href="http://svn.apache.org/viewvc?view=rev&rev=1725263";>1725263</a> and
+ <a
href="http://svn.apache.org/viewvc?view=rev&rev=1725914";>1725914</a>.</p>
+
+
+<p>This issue was identified by the Tomcat security team on 12 November 2015
+ and made public on 22 February 2016.</p>
+
+
+<p>Affects: 9.0.0.M1</p>
+
</div>
</div>
Modified: tomcat/site/trunk/xdocs/security-6.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-6.xml?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-6.xml (original)
+++ tomcat/site/trunk/xdocs/security-6.xml Mon Feb 22 11:21:42 2016
@@ -48,6 +48,105 @@
</section>
+ <section name="Fixed in Apache Tomcat 6.0.45" rtext="11 February 2016">
+
+ <p><strong>Low: Limited directory traversal</strong>
+ <cve>CVE-2015-5174</cve></p>
+
+ <p>When accessing resources via the <code>ServletContext</code> methods
+ <code>getResource()</code> <code>getResourceAsStream()</code> and
+ <code>getResourcePaths()</code> the paths should be limited to the
+ current web application. The validation was not correct and paths of the
+ form <code>"/.."</code> were not rejected. Note that paths starting with
+ <code>"/../"</code> were correctly rejected. This bug allowed malicious
+ web applications running under a security manager to obtain a directory
+ listing for the directory in which the web application had been
deployed.
+ This should not be possible when running under a security manager.
+ Typically, the directory listing that would be exposed would be for
+ <code>$CATALINA_BASE/webapps.</code></p>
+
+ <p>This was fixed in revision <revlink rev="1700900">1700900</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 August 2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 6.0.0 to 6.0.44</p>
+
+ <p><strong>Low: Directory disclosure</strong>
+ <cve>CVE-2015-5345</cve></p>
+
+ <p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+ <p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+ <p>This was fixed in revisions <revlink rev="1715216">1715216</revlink> and
+ <revlink rev="1717216">1717216</revlink>.</p>
+
+ <p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+ <p>Affects: 6.0.0 to 6.0.44</p>
+
+ <p><strong>Low: Security Manager bypass</strong>
+ <cve>CVE-2016-0706</cve></p>
+
+ <p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+ <p>This was fixed in revision <revlink rev="1722802">1722802</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 27 December
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 6.0.0 to 6.0.44</p>
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0714</cve></p>
+
+ <p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+ <p>This was fixed in revisions <revlink rev="1727166">1727166</revlink> and
+ <revlink rev="1727182">1727182</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 November
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 6.0.0 to 6.0.44</p>
+
+ </section>
+
<section name="Fixed in Apache Tomcat 6.0.44" rtext="12 May 2015">
<p><strong>Low: Denial of Service</strong>
Modified: tomcat/site/trunk/xdocs/security-7.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-7.xml?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-7.xml (original)
+++ tomcat/site/trunk/xdocs/security-7.xml Mon Feb 22 11:21:42 2016
@@ -50,6 +50,174 @@
</section>
+ <section name="Fixed in Apache Tomcat 7.0.68" rtext="16 February 2016">
+
+ <p><strong>Low: CSRF token leak</strong>
+ <cve>CVE-2015-5351</cve></p>
+
+ <p>The index page of the Manager and Host Manager applications included a
+ valid CSRF token when issuing a redirect as a result of an
+ unauthenticated request to the root of the web application. This token
+ could then be used by an attacker to construct a CSRF attack.</p>
+
+ <p>This was fixed in revisions <revlink rev="1720661">1720661</revlink> and
+ <revlink rev="1720663">1720663</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 8 December 2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.1 to 7.0.67</p>
+
+ <p><strong>Low: Security Manager bypass</strong>
+ <cve>CVE-2016-0706</cve></p>
+
+ <p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+ <p>This was fixed in revision <revlink rev="1722801">1722801</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 27 December
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.0 to 7.0.67</p>
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0714</cve></p>
+
+ <p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+ <p>This was fixed in revisions <revlink rev="1726923">1726923</revlink> and
+ <revlink rev="1727034">1727034</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 November
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.0 to 7.0.67</p>
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0763</cve></p>
+
+ <p><code>ResourceLinkFactory.setGlobalContext()</code> is a public method
+ and was accessible by web applications running under a security manager
+ without any checks. This allowed a malicious web application to inject a
+ malicious global context that could in turn be used to disrupt other web
+ applications and/or read and write data owned by other web
+ applications.</p>
+
+ <p>This was fixed in revision <revlink rev="1725931">1725931</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 18 January 2016
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.0 to 7.0.67</p>
+
+ </section>
+
+ <section name="Fixed in Apache Tomcat 7.0.67" rtext="10 December 2015">
+
+ <p><strong>Low: Directory disclosure</strong>
+ <cve>CVE-2015-5345</cve></p>
+
+ <p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+ <p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+ <p>This was fixed in revisions <revlink rev="1715213">1715213</revlink> and
+ <revlink rev="1717212">1717212</revlink>.</p>
+
+ <p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.0 to 7.0.66</p>
+
+ <p><i>Note: The issue below was fixed in Apache Tomcat 7.0.66 but the
+ release vote for the 7.0.66 release candidate did not pass. Therefore,
+ although users must download 7.0.67 to obtain a version that includes a
+ fix for this issue, version 7.0.66 is not included in the list of
+ affected versions.</i></p>
+
+ <p><strong>Low: Session Fixation</strong>
+ <cve>CVE-2015-5346</cve></p>
+
+ <p>When recycling the <code>Request</code> object to use for a new request,
+ the <code>requestedSessionSSL</code> field was not recycled. This meant
that
+ a session ID provided in the next request to be processed using the
recycled
+ <code>Request</code> object could be used when it should not have been.
This
+ gave the client the ability to control the session ID. In theory, this
could
+ have been used as part of a session fixation attack but it would have been
+ hard to achieve as the attacker would not have been able to force the
victim
+ to use the 'correct' <code>Request</code> object. It was also necessary for
+ at least one web application to be configured to use the SSL session ID as
+ the HTTP session ID. This is not a common configuration.</p>
+
+ <p>This was fixed in revision <revlink rev="1713187">1713187</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 22 June 2014
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.5 to 7.0.65</p>
+
+ </section>
+
+ <section name="Fixed in Apache Tomcat 7.0.65" rtext="19 October 2015">
+
+ <p><strong>Low: Limited directory traversal</strong>
+ <cve>CVE-2015-5174</cve></p>
+
+ <p>When accessing resources via the <code>ServletContext</code> methods
+ <code>getResource()</code> <code>getResourceAsStream()</code> and
+ <code>getResourcePaths()</code> the paths should be limited to the
+ current web application. The validation was not correct and paths of the
+ form <code>"/.."</code> were not rejected. Note that paths starting with
+ <code>"/../"</code> were correctly rejected. This bug allowed malicious
+ web applications running under a security manager to obtain a directory
+ listing for the directory in which the web application had been
deployed.
+ This should not be possible when running under a security manager.
+ Typically, the directory listing that would be exposed would be for
+ <code>$CATALINA_BASE/webapps.</code></p>
+
+ <p>This was fixed in revisions <revlink rev="1696284">1696284</revlink> and
+ <revlink rev="1700898">1700898</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 August 2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 7.0.0 to 7.0.64</p>
+
+ </section>
+
<section name="Fixed in Apache Tomcat 7.0.59" rtext="4 February 2015">
<p><i>Note: The issue below was fixed in Apache Tomcat 7.0.58 but the
Modified: tomcat/site/trunk/xdocs/security-8.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-8.xml?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-8.xml (original)
+++ tomcat/site/trunk/xdocs/security-8.xml Mon Feb 22 11:21:42 2016
@@ -50,12 +50,181 @@
</section>
+ <section name="Fixed in Apache Tomcat 8.0.32" rtext="8 February 2016">
+
+ <p><i>Note: The issues below were fixed in Apache Tomcat 8.0.31 but the
+ release vote for the 8.0.31 release candidate did not pass. Therefore,
+ although users must download 8.0.32 to obtain a version that includes
+ fixes for these issues, version 8.0.31 is not included in the list of
+ affected versions.</i></p>
+
+ <p><strong>Low: Session Fixation</strong>
+ <cve>CVE-2015-5346</cve></p>
+
+ <p>When recycling the <code>Request</code> object to use for a new request,
+ the <code>requestedSessionSSL</code> field was not recycled. This meant
that
+ a session ID provided in the next request to be processed using the
recycled
+ <code>Request</code> object could be used when it should not have been.
This
+ gave the client the ability to control the session ID. In theory, this
could
+ have been used as part of a session fixation attack but it would have been
+ hard to achieve as the attacker would not have been able to force the
victim
+ to use the 'correct' <code>Request</code> object. It was also necessary for
+ at least one web application to be configured to use the SSL session ID as
+ the HTTP session ID. This is not a common configuration.</p>
+
+ <p>This was fixed in revisions <revlink rev="1713185">1713185</revlink> and
+ <revlink rev="1723506">1723506</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 22 June 2014
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+ <p><strong>Low: CSRF token leak</strong>
+ <cve>CVE-2015-5351</cve></p>
+
+ <p>The index page of the Manager and Host Manager applications included a
+ valid CSRF token when issuing a redirect as a result of an
+ unauthenticated request to the root of the web application. This token
+ could then be used by an attacker to construct a CSRF attack.</p>
+
+ <p>This was fixed in revisions <revlink rev="1720658">1720658</revlink> and
+ <revlink rev="1720660">1720660</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 8 December 2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+ <p><strong>Low: Security Manager bypass</strong>
+ <cve>CVE-2016-0706</cve></p>
+
+ <p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+ <p>This was fixed in revision <revlink rev="1722800">1722800</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 27 December
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0714</cve></p>
+
+ <p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+ <p>This was fixed in revisions <revlink rev="1726196">1726196</revlink> and
+ <revlink rev="1726203">1726203</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 November
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0763</cve></p>
+
+ <p><code>ResourceLinkFactory.setGlobalContext()</code> is a public method
+ and was accessible by web applications running under a security manager
+ without any checks. This allowed a malicious web application to inject a
+ malicious global context that could in turn be used to disrupt other web
+ applications and/or read and write data owned by other web
+ applications.</p>
+
+ <p>This was fixed in revision <revlink rev="1725929">1725929</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 18 January 2016
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.30</p>
+
+ </section>
+
+ <section name="Fixed in Apache Tomcat 8.0.30" rtext="6 December 2015">
+
+ <p><strong>Low: Directory disclosure</strong>
+ <cve>CVE-2015-5345</cve></p>
+
+ <p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+ <p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+ <p>This was fixed in revisions <revlink rev="1715207">1715207</revlink> and
+ <revlink rev="1717209">1717209</revlink>.</p>
+
+ <p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0.RC1 to 8.0.29</p>
+
+ </section>
+
+ <section name="Fixed in Apache Tomcat 8.0.27" rtext="1 October 2015">
+
+ <p><strong>Low: Limited directory traversal</strong>
+ <cve>CVE-2015-5174</cve></p>
+
+ <p>When accessing resources via the <code>ServletContext</code> methods
+ <code>getResource()</code> <code>getResourceAsStream()</code> and
+ <code>getResourcePaths()</code> the paths should be limited to the
+ current web application. The validation was not correct and paths of the
+ form <code>"/.."</code> were not rejected. Note that paths starting with
+ <code>"/../"</code> were correctly rejected. This bug allowed malicious
+ web applications running under a security manager to obtain a directory
+ listing for the directory in which the web application had been
deployed.
+ This should not be possible when running under a security manager.
+ Typically, the directory listing that would be exposed would be for
+ <code>$CATALINA_BASE/webapps.</code></p>
+
+ <p>This was fixed in revisions <revlink rev="1696281">1696281</revlink> and
+ <revlink rev="1700897">1700897</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 August 2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 8.0.0-RC1 to 8.0.26</p>
+
+ </section>
+
<section name="Fixed in Apache Tomcat 8.0.17" rtext="16 January 2015">
<p><i>Note: The issue below was fixed in Apache Tomcat 8.0.16 but the
release vote for the 8.0.16 release candidate did not pass. Therefore,
although users must download 8.0.17 to obtain a version that includes a
- fix for this issue, versions 8.0.16 is not included in the list of
+ fix for this issue, version 8.0.16 is not included in the list of
affected versions.</i></p>
<p><strong>Moderate: Security Manager bypass</strong>
Modified: tomcat/site/trunk/xdocs/security-9.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-9.xml?rev=1731626&r1=1731625&r2=1731626&view=diff
==============================================================================
--- tomcat/site/trunk/xdocs/security-9.xml (original)
+++ tomcat/site/trunk/xdocs/security-9.xml Mon Feb 22 11:21:42 2016
@@ -50,11 +50,146 @@
</section>
- <section name="Fixed in Apache Tomcat 9.0.x">
+ <section name="Fixed in Apache Tomcat 9.0.0.M3" rtext="5 January 2016">
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0763</cve></p>
+
+ <p><code>ResourceLinkFactory.setGlobalContext()</code> is a public method
+ and was accessible by web applications running under a security manager
+ without any checks. This allowed a malicious web application to inject a
+ malicious global context that could in turn be used to disrupt other web
+ applications and/or read and write data owned by other web
+ applications.</p>
+
+ <p>This was fixed in revision <revlink rev="1725926">1725926</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 18 January 2016
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 9.0.0.M1 to 9.0.0.M2</p>
+
+ <p><i>Note: The issues below were fixed in Apache Tomcat 9.0.0.M2 but the
+ release vote for the 9.0.0.M2 release candidate did not pass. Therefore,
+ although users must download 9.0.0.M3 to obtain a version that includes
+ fixes for these issues, version 9.0.0.M2 is not included in the list of
+ affected versions.</i></p>
+
+ <p><strong>Low: Directory disclosure</strong>
+ <cve>CVE-2015-5345</cve></p>
+
+ <p>When accessing a directory protected by a security constraint with a URL
+ that did not end in a slash, Tomcat would redirect to the URL with the
+ trailing slash thereby confirming the presence of the directory before
+ processing the security constraint. It was therefore possible for a user
+ to determine if a directory existed or not, even if the user was not
+ permitted to view the directory. The issue also occurred at the root of
a
+ web application in which case the presence of the web application was
+ confirmed, even if a user did not have access.</p>
+
+ <p>The solution was to implement the redirect in the DefaultServlet so that
+ any security constraints and/or security enforcing Filters were
processed
+ before the redirect. The Tomcat team recognised that moving the redirect
+ could cause regressions to two new Context configuration options
+ (<code>mapperContextRootRedirectEnabled</code> and
+ <code>mapperDirectoryRedirectEnabled</code>) were introduced. The
initial
+ default was <code>false</code> for both since this was more secure.
+ However, due to regressions such as
+ <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765";>Bug
+ 58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
+ was later changed to true since it was viewed that the regression was
+ more serious than the security risk of associated with being able to
+ determine if a web application was deployed at a given path.</p>
+
+ <p>This was fixed in revisions <revlink rev="1715206">1715206</revlink>,
+ <revlink rev="1716882">1716882</revlink> and
+ <revlink rev="1716894">1716894</revlink>.</p>
+
+ <p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
+ made public on 22 February 2016.</p>
+
+ <p>Affects: 9.0.0.M1</p>
+
+ <p><strong>Low: Session Fixation</strong>
+ <cve>CVE-2015-5346</cve></p>
+
+ <p>When recycling the <code>Request</code> object to use for a new request,
+ the <code>requestedSessionSSL</code> field was not recycled. This meant
that
+ a session ID provided in the next request to be processed using the
recycled
+ <code>Request</code> object could be used when it should not have been.
This
+ gave the client the ability to control the session ID. In theory, this
could
+ have been used as part of a session fixation attack but it would have been
+ hard to achieve as the attacker would not have been able to force the
victim
+ to use the 'correct' <code>Request</code> object. It was also necessary for
+ at least one web application to be configured to use the SSL session ID as
+ the HTTP session ID. This is not a common configuration.</p>
+
+ <p>This was fixed in revisions <revlink rev="1713184">1713184</revlink> and
+ <revlink rev="1723414">1723414</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 22 June 2014
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 9.0.0.M1</p>
+
+ <p><strong>Low: CSRF token leak</strong>
+ <cve>CVE-2015-5351</cve></p>
+
+ <p>The index page of the Manager and Host Manager applications included a
+ valid CSRF token when issuing a redirect as a result of an
+ unauthenticated request to the root of the web application. This token
+ could then be used by an attacker to construct a CSRF attack.</p>
+
+ <p>This was fixed in revisions <revlink rev="1720652">1720652</revlink> and
+ <revlink rev="1720655">1720655</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 8 December 2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 9.0.0.M1</p>
+
+ <p><strong>Low: Security Manager bypass</strong>
+ <cve>CVE-2016-0706</cve></p>
+
+ <p>The StatusManagerServlet could be loaded by a web application when a
+ security manager was configured. This servlet would then provide the web
+ application with a list of all deployed applications and a list of the
+ HTTP request lines for all requests currently being processed. This
could
+ have exposed sensitive information from other web applications such as
+ session IDs to the web application.</p>
+
+ <p>This was fixed in revision <revlink rev="1722799">1722799</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 27 December
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 9.0.0.M1</p>
+
+ <p><strong>Moderate: Security Manager bypass</strong>
+ <cve>CVE-2016-0714</cve></p>
+
+ <p>Tomcat provides several session persistence mechanisms. The
+ <code>StandardManager</code> persists session over a restart. The
+ <code>PersistentManager</code> is able to persist sessions to files, a
+ database or a custom <code>Store</code>. The cluster implementation
+ persists sessions to one or more additional nodes in the cluster. All of
+ these mechanisms could be exploited to bypass a security manager.
Session
+ persistence is performed by Tomcat code with the permissions assigned to
+ Tomcat internal code. By placing a carefully crafted object into a
+ session, a malicious web application could trigger the execution of
+ arbitrary code.</p>
+
+ <p>This was fixed in revisions <revlink rev="1725263">1725263</revlink> and
+ <revlink rev="1725914">1725914</revlink>.</p>
+
+ <p>This issue was identified by the Tomcat security team on 12 November
2015
+ and made public on 22 February 2016.</p>
+
+ <p>Affects: 9.0.0.M1</p>
- <p>There are currently no known vulnerabilities for Apache Tomcat 9.0.x</p>
</section>
+
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
