Today we are announcing the availability of quarterly servicing updates, cumulative and update rollups, for all supported versions of Exchange Server. Exchange Server 2010, 2013, 2016 and 2019 all re...
Updated Jul 01, 2019
Version 2.0
Blog Post
Thanks for this full detailed description guys, however still one open question on the vulnerability part.
CVE-2018-8581 initially talked about removing the DisableLoopBackCheck Key:
To address this vulnerability, a registry value which enables NTLM authentication on the network loopback adapter needs to be removed. Future cumulative updates will ensure that this registry setting is configured correctly during installation of the cumulative update.
---
We have removed this key on our EX2016 CU11 Servers to be on the safe side and didn't see any negative side effects so far. Is this key also being removed during CU12 install and the recommendation above still valid even after the changes been implemented with the updates been released today?
Thanks for clarifying!
- @Martin, yes the CU's released today should remove this key, if present. The 2010 RU will not remove the key. There's no harm if you have already done this, it will not interfere with CU installation.
- Hi Brent. If DisableLoopbackCheck is now being disabled in all 2013+ CUs, why was it still in-place? Does this mean Exchange Server has been unwinding a default security feature that's been around for something like 15 years for no benefit? And why didn't the Exchange team push BackConnectionHostNames guidance as is common in other web technologies like SharePoint?
- @Tristan - There have been legitimate reasons for Exchange to enable this. We are hearing some reports of certain Exchange monitoring tools requiring loopback to be enabled. We will look to change the behavior of these cmdlets. But honestly it appears to have been an optimization that was made for reasons that may no longer apply to Exchange code, a long time ago. In general we don't like to change behavior that has existed for a very long time due to the surface area that Exchange covers and the risk of regression. In this case however, closing a security hole made that a requirement. Our preference is to remove dependence on NTLM altogether in the product and that is the work that has been more important to us and that we have been working on.
It is a minor optimization based upon reports coming in from SCOM. We likely have to update our cmdlets, but I don't want to give the impression we haven't tested the cmdlets. It's hard for us to tell in a one-box topology what is real and what isn't when tests fail sometimes.