Thank you for this latest update. 
Looking forward for the 7.x new build.

Sent from my iPhone

> On Sep 29, 2017, at 2:14 AM, Mark Thomas <ma...@apache.org> wrote:
> 
> 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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to