Thank you for the response and confirmation, Mark. Sent from my iPhone
> On Sep 25, 2017, at 12:36 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 25/09/17 18:12, Harish Krishnan wrote: >> Hi Mark, >> >> Thanks for the timely updates. >> My understanding is, there will be a new 7.x update available for addressing >> CVE-2017-12617. Is that correct? >> The current latest (7.0_81) resolves the initial 2 CVEs (CVE*12615 and >> CVE*12616). >> When can we expect the new update for 7.x? > > Over the weekend we received an additional report that demonstrated a > way of bypassing the fix for CVE-2017-12615. The changes we have already > made for CVE-2017-12617 also block this additional attack vector but not > as cleanly as we would like. Therefore we intend to make some additional > changes and re-tag 9.0.x and 8.5.x. > > Separately, testing has identified a regression in the 7.0.x back-port > which will need to be addressed before 7.0.x is tagged. > > Timings are hard to guarantee but I think we are looking at tags in the > next 24 hours or so, release votes complete in anything up 72 hours > after that (less if folks vote quickly) and the release on the mirrors 6 > to 12 hours after that. We might just make the weekend but early next > week seems more realistic. > > Mark > >> >> Sent from my iPhone >> >>> On Sep 22, 2017, at 2:21 AM, Mark Thomas <ma...@apache.org> wrote: >>> >>> Update: >>> >>> The review did not identify any further security concerns but it did >>> identify a handful of places where the code could benefit from some >>> clean-up. This clean-up makes the purpose of the code clearer and eases >>> future maintenance in this security-relevant area of the code base. >>> >>> The clean-up has been implemented and reviewed. Back-ports have been >>> completed for 8.5.x and 8.0.x. 7.0.x is in progress but requires a >>> little more time as 7.0.x uses the JNDI based resources implementation >>> that was replaced in 8.0.x onwards. >>> >>> The current expectation is that the releases will be tagged and votes >>> started later today. >>> >>> Mark >>> >>> >>>> On 20/09/17 17:37, Mark Thomas wrote: >>>> Update: >>>> >>>> We believe we have a set of patches [1],[2] that addresses this for >>>> 9.0.x. The plan is to give folks ~12 hours to review the proposed >>>> patches and then back-port the patches, tag and release. >>>> >>>> Further analysis has not identified any additional attack vectors or >>>> risks associated with this vulnerability. >>>> >>>> The recommended mitigations remain unchanged. >>>> >>>> Mark >>>> >>>> >>>> [1] http://svn.apache.org/viewvc?rev=1809011&view=rev >>>> [2] http://svn.apache.org/viewvc?rev=1809025&view=rev >>>> >>>> >>>>> On 20/09/17 13:20, Mark Thomas wrote: >>>>> Update: >>>>> >>>>> The issue has been confirmed. >>>>> >>>>> CVE-2017-12617 has been allocated. >>>>> >>>>> The issue is not limited to PUT requests. For the Default servlet, >>>>> DELETE is known to be affected. For the WebDAV servlet DELETE, MOVE and >>>>> COPY are believed to be affected. >>>>> >>>>> The RCE via JSP upload using PUT is still believed to be the most severe >>>>> impact of this vulnerability. >>>>> >>>>> The recommended mitigations remain unchanged. >>>>> >>>>> Mark >>>>> >>>>> >>>>>> On 20/09/17 09:25, Mark Thomas wrote: >>>>>> All, >>>>>> >>>>>> Following the announcement of CVE-2017-12615 [1], the Apache Tomcat >>>>>> Security Team has received multiple reports that a similar vulnerability >>>>>> exists in all current Tomcat versions and affects all operating systems. >>>>>> >>>>>> Unfortunately, one of these reports was made via the public bug tracker >>>>>> [2] rather than responsibly via the Tomcat Security Team's private >>>>>> mailing list [3]. >>>>>> >>>>>> We have not yet completed our investigation of these reports but, based >>>>>> on the volume, and our initial investigation they appear to be valid. >>>>>> >>>>>> From an initial analysis of the reports received, the vulnerability only >>>>>> affects the following configurations: >>>>>> >>>>>> Default Servlet >>>>>> - Default Servlet configured with readonly="false" >>>>>> AND >>>>>> - Untrusted users are permitted to perform HTTP PUT requests >>>>>> >>>>>> WebDAV Servlet >>>>>> - WebDAV Servlet configured with readonly="false" >>>>>> AND >>>>>> - Untrusted users are permitted to perform HTTP PUT requests >>>>>> AND >>>>>> - The documented advice not to map the WebDAV servlet as the Default >>>>>> servlet has been ignored >>>>>> >>>>>> Please note that: >>>>>> - The WebDAV servlet is disabled by default >>>>>> - The default value for the readonly parameter is true for both the >>>>>> Default servlet and the WebDAV servlet >>>>>> >>>>>> Therefore, a default Tomcat installation is not affected by this >>>>>> potential vulnerability. >>>>>> >>>>>> Based on our understanding to date, the potential vulnerability may be >>>>>> mitigated by any of the following: >>>>>> - setting readonly to true for the Default servlet and WebDAV servlet >>>>>> - blocking HTTP methods that permit resource modification for untrusted >>>>>> users >>>>>> >>>>>> We will provide updates to the community as our investigation of these >>>>>> reports continues. >>>>>> >>>>>> Mark >>>>>> on behalf of the Apache Tomcat Security Team >>>>>> >>>>>> >>>>>> [1] http://markmail.org/message/xqfchebiy6fjmvjz >>>>>> [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=61542 >>>>>> [3] http://tomcat.apache.org/security.html >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
