Be advised that these security updates will disable Oracle Outside In Technology (OIT). Security issues have been discovered in this embedded third-party package (ADV24199947). The consequence of disabling these is that text can no longer be extracted from JPG, TIFF, and AutoCAD files for usage in Exchange Transport Rules or Data Loss Prevention rules. More information is here.
Fixed Issues
Apart from security fixes, these Security Updates also correct the following issues:
Security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU14 to Exchange 2019 CU13. When downloading, the security update will carry the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level when archiving it, e.g., Exchange2019-CU13-KBXXXXXX-x64-en.msp.
Similar to Cumulative Updates, Security Updates are cumulative, and you only need to install the latest SU for your CU.
If you have deployed Exchange Management Tools to manage your on-premises Exchange Servers or installed the tools after removal of the Last Exchange Server for recipient management, it is recommended to apply the Security Update. Be aware of few cmdlet piping issues mentioned here.
On a final note, as with any patch or update, it is recommended to apply this in a test environment first prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates and follow a more agile approach; the ratings are an indication of the urgency.
Be advised that these updates will enable payload signing by default. Payload serialization signing signs PowerShell payloads to identify possible tampering. Support for certificate-based signing of PowerShell serialization payloads got added with January security updates and is a per-server configuration. In other words, make sure you have deployed the January security updates before implementing these security updates, so your Exchange servers support payload signing before you can enable it one server at a time.
Security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU13 to Exchange 2019 CU12. When downloading, the security update will carry the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level when archiving it, e.g., Exchange2019-CU13-KBXXXXXX-x64-en.msp.
Similar to Cumulative Updates, Security Updates are cumulative, and you only need to install the latest SU for your CU.
If you have deployed Exchange Management Tools to manage your on-premises Exchange Servers or installed the tools after removal of the Last Exchange Server for recipient management, it is recommended to apply the Security Update. Be aware of few cmdlet piping issues mentioned here.
On a final note, as with any patch or update, it is recommended to apply this in a test environment first prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates and follow a more agile approach; the ratings are an indication of the urgency.
The recommendation for the August updates was to disable the TokenCacheModule in IIS to mitigate an Elevation of Privilege issue in IIS. That issue is fixed with a Windows update for CVE-2023-36434. Thus, after installing this update for IIS, it is no longer recommended to disable TokenCacheModule. When you have disabled it after installing the August 2023 updates, you can enable it again using New-WebGlobalModule -Name "TokenCacheModule" -Image "%windir%\System32\inetsrv\cachtokn.dll", or use the CVE-2023-21709.ps1 script specifying the -Rollback switch to (re-)enable it on all of your Exchange servers.
Fixed Issues
Apart from security fixes, these Security Updates also correct the following issues:
Extended Protection causes Outlook for Mac to fail to download the OAB (use updated Extended Protection script)
Yes
Yes
Notes
Security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU13 to Exchange 2019 CU12. When downloading, the security update will carry the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level when archiving it, e.g., Exchange2019-CU13-KBXXXXXX-x64-en.msp.
Similar to Cumulative Updates, Security Updates are cumulative, and you only need to install the latest SU for your CU.
If you have installed the Exchange Management Tools separately for managing your on-premises Exchange Servers or installed it after removal of the Last Exchange Server for recipient management, it is recommended to apply the Security Update.
On a final note, as with any patch or update, it is recommended to apply this in a test environment first prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates and follow a more agile approach; the ratings are an indication of the urgency.
CVE-2023-21709 requires additional steps, which need to be performed after installing the August updates. These steps will remove the TokenCacheModule from IIS, preventing IIS (thus implicitly Exchange) from caching security tokens for password-authenticated sessions (Anonymous, BasicAuth, and Client Certificates) at a performance penalty as every request needs to get re-authenticated. Documentation on these steps, as well as a script to implement or undo these changes, can be found here.
Update October 10: Removal of TokenCacheModule is no longer recommended, as the vulnerability has been addressed in a Windows patch, CVE-2023-36434.
AES256 in Cipher Block Chaining mode
After installing these August updates, AES256-CBC will be the default encryption mode. In order to allow decrypting of Microsoft Purview Information Protection or Active Directory Rights Management Services, additional configuration is required. If you utilize RMS with Exchange on-premises, consult the steps in this KB article.
Issue with Non-English Operating Systems
The issue with the initial release of the August 2023 SU’s has been fixed in the V2 versions. Take note of the What-if table in the August SU V2 publication on how to proceed if you already installed V1 using the workaround. TLDR;:
If you installed V1 successfully (English OS), no action is needed, and installing V2 is optional (will only increase Exchange build numbers).
If you installed V1 on a non-English OS with the workaround, uninstall August SU V1, restart, install August SU V2, and clean up the workaround (dummy ‘Network Service’ account)
If you did not install V1 on a non-English OS or tried installing without success and re-enabled services using ServiceControl.ps1 -AfterPatch, install the August SU V2 update.
Right after the release of the Security Update, reports came in from customers with failed deployments for non-English operating systems. Installing the SU failed, leaving their Exchange server in a non-functional state as Exchange-related services were disabled. After Microsoft investigated the issue, it was found the SU installer uses the textual “Network Service” security principal during configuration. This does not work in other languages, where it needs to be the localized name, e.g. Netzwerkdienst (German) or SERVICE LOCAL (French). Using the well-known SID for this service principal (S-1-5-20), or using this to look up the actual name, would be the way to address this. This is also what the workaround in the support article is basically doing:
Restore the startup state of Echange services using $exscripts\ServiceControl.ps1 AfterPatch.
Creating a dummy “Network Service” account.
Manually add Full Control on the ACL of HKLM:\SOFTWARE\Microsoft\MSIPC\Server for the ‘real’ Network Service security principal, which is what the SU should be doing. Under this key is where licenses used for Azure Information Protection are stored.
While having a workaround helps, it is not very maintainable, which is why I expect Microsoft to publish an update for the Security Update. Also, the whole situation gives to think about the mindset of developers who apparently only test using English operating systems. With still significant on-premises Exchange presence in countries such as Germany and France, making code OS language-independent and having it tested could use improvement.
Fixed Issues
Apart from security fixes, these Security Updates also correct the following issues:
Security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU13 to Exchange 2019 CU12. When downloading, the security update will carry the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level when archiving it, e.g., Exchange2019-CU13-KBXXXXXX-x64-en.msp.
Similar to Cumulative Updates, Security Updates are cumulative, and you only need to install the latest SU for your CU.
If you have installed the Exchange Management Tools separately for managing your on-premises Exchange Servers or installed it after removal of the Last Exchange Server for recipient management, it is recommended to apply the Security Update.
On a final note, as with any patch or update, I’d recommend applying this in a test environment first prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates and follow a more agile approach; the ratings are an indication of the urgency.
Security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2019 CU12 to Exchange 2019 CU11. When downloading, the security update will carry the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level when archiving it, e.g. Exchange2019-CU13-KBXXXXXX-x64-en.msp.
Similar to Cumulative Updates, Security Updates are cumulative and you only need to install the latest SU for your CU.
Exchange servers running as part of hybrid deployment are managed through PowerShell, and thus need to be receive this patch and eventually be enabled for payload signing.
If you have installed the Exchange Management Tools separately for managing your on-premises Exchange Servers, or installed it after removal of the Last Exchange Server for recipient management, it is recommended to apply the Security Update.
On a final note, as with any patch or update, I’d recommend to apply this in a test environment first, prior to implementing it in production. However, it is not recommended to wait for regular maintenance cycles when it concerns security updates, and follow a more agile approach; the ratings are an indication of the urgency.
EighTwOne (821) 