Hi all, Hopefully this will be the final update on this.
The fixes for CVE-2017-12617 have now been applied to all current versions. Releases for 9.0.x and 8.5.x are already in progress on the dev@ list. The release process for 8.0.x and 7.0.x is expected to start shortly. As per my previous e-mail, I expect the releases to be announced over the weekend / early next week. Mark On 26/09/17 02:22, Harish Krishnan wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
