Microsoft hat neue Sicherheitsupdates für Exchange 2013, 2016 und 2019 veröffentlicht. Es werden insgesamt 4 als wichtig eingestufte Schwachstellen behoben. Details zu den geschlossenen Schwachstellen finden sich hier:
- CVE-2023-21707 – Microsoft Exchange Server Remote Code Execution Vulnerability
- CVE-2023-21706 – Microsoft Exchange Server Remote Code Execution Vulnerability
- CVE-2023-21710 – Microsoft Exchange Server Remote Code Execution Vulnerability
- CVE-2023-21529 – Microsoft Exchange Server Remote Code Execution Vulnerability
Wie zu sehen ist, handelt es sich bei allen 4 Schwachstellen um Remote Code Execution Schwachstellen, die Updates sollten daher möglichst zeitnah installiert werden.
Hier geht es direkt zum Download der Updates:
Hier findet sich der Artikel aus dem Exchange Team Blog:
Auch meine Seite zu den jeweils aktuellen Exchange Versionen habe ich bereits aktualisiert:
Dort findet sich auch die Möglichkeit, direkt bei Veröffentlichung von Updates eine Mail zu erhalten.
Update 15.02.: Wer das Exchange SU vor dem 15.02.20233 17:00 Uhr via Windows Update installiert hat, darf noch mal ran. Windows Update hat das Januar SU ausgeliefert und nicht das aktuelle Februar SU. Wie schon oft erwähnt ist der sicherste und stabilste Weg für die Installation von Exchange Update, das EXE Paket und nicht der Weg via Windows Update. Dazu der Hinweis vom Exchange Team Blog:
Note: Build availability issues have been resolved. If your server downloaded the February SU via Windows/ Microsoft update before February 15 8 AM Pacific time, you might see the February update be offered again. Installing the updated package will bring your server forward to current February builds (verify using Health Checker after installation). The Download Center .exe update packages were (and still are) correct.
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058
Update 16.02: Nach der Installation des SU kann es auf Exchange 2016 / 2019 Servern zu dem Problem kommen, dass der EWS Application Pool im IIS abstürzt. Im Eventlog wird das Ereignis 4999 mit der folgenden Meldung protokolliert:
E12IIS, c-RTL-AMD64, 15.01.2507.021, w3wp#MSExchangeServicesAppPool, M.Exchange.Diagnostics, M.E.D.ChainedSerializationBinder.EnforceBlockReason, M.E.Diagnostics.BlockedDeserializeTypeException, 437c-dumptidset, 15.01.2507.021.
Der folgende Workaround wurde auf dem Exchange Team Blog veröffentlicht:
1. Create the following regkey in the exchange servers: SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics\DisableBaseTypeCheckForDeserialization
The regkey is ‘string value’ type and needs to have a value of 1.
2. Create the below setting override:
- New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server <ServerName> -Component Data -Section DeserializationBinderSettings -Parameters @(„LearningLocations=ClientExtensionCollectionFormatter“) -Reason „Deserialization failed“
- Force the application of the setting by running the following:
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart IIS app pools.
