Catulize.de
Y2K22-Fehler: Exchange-Server auf der ganzen Welt beschädigt

Geschrieben am 01.01.2022

Für viele ist das neue Jahr eine Zeit, die sie mit Familie und Freunden verbringen, und eine Zeit, in der sie lockere und hoffnungsvolle Beschlüsse in Form von Vorsätzen für das neue Jahr fassen. Für Sysadmins, die für Exchange-Server verantwortlich sind, war es eine ganz andere Geschichte, da Microsoft Exchange-Server nicht in der Lage waren, das neue Datum ordnungsgemäß zu verarbeiten, und daher keine E-Mails verarbeiten konnten.


Die erste Meldung hierzu kam um 1 Uhr EST vom Reddit-Benutzer /u/FST-LANE, der vermutete, dass Microsoft ein fehlerhaftes Update mit dem treffenden Namen "220101001" veröffentlicht hat. Dies war vermutlich ein geplanter Patch, um die Verarbeitung des neuen Datums zu ermöglichen, aber es verlief nicht wie geplant. "Ich sehe eine Reihe von Fehlern vom FIPFS-Dienst, die besagen: Cannot convert "220101001" to long", schrieb /u/FST-LANE.


Dies deckt sich mit Berichten von Marius Sandbu, Manager bei der norwegischen Firma Sopra Steria, der eine detaillierte Übersicht über die Ursache veröffentlichte. Er berichtet, dass Microsoft Exchange Server die Verarbeitung von E-Mails komplett eingestellt haben, weil sie nicht auf das heutige Datum vorbereitet sind. Er erklärt: "Der Grund dafür ist, dass Microsoft einen signierten int32 für das Datum verwendet und mit dem neuen Wert von 2.201.010.001 den maximalen Wert des "long" int von 2.147.483.647 überschreitet."


Dies führt nun dazu - zumindest was bisher bekannt ist - dass ausgehende Mails in der Transportqueue festgehalten werden. Resultierend daraus und aus den endlosen Logfiles die generiert werden, dauert es unter umständen bei einigen Systemen nicht lange, bis die Festplatten volllaufen.


Der beunruhigendste Teil dieses Problems ist die Notlösung. Um die Verarbeitung von E-Mails fortzusetzen, deaktivieren Systemadministratoren das Scannen von Malware auf ihren Exchange-Servern, wodurch ihre Benutzer und möglicherweise auch die Server selbst anfällig für Angriffe sind.


Office365 - Exchange Online Nutzer sind davon nicht betroffen. Unter anderem aus solchen Gründen empfehlen wir den Umstieg zu Office365 ggf. in der kleinsten Version mit dem Online Plan 1. Sie können uns jederzeit dazu ansprechen.


Lösung


Aktuell scheint dies der einzige Workaround durch Microsoft zu sein, um einen Exchange-Server vor dem Überlaufen der Festplatten zu verschonen.


Update: siehe neuen Blogeintrag


Allerdings melden andere Administratoren, dass dies das Problem nicht behebe. Eine offizielle Stellungnahme von Microsoft steht bislang noch aus.


Workaround: Antimalware-Scanning deaktivieren


Für Exchange Server gibt es ein PowerShell-Script Disable-AntiMalwareScanning.ps1, welches die Scan Engine deaktiviert. Als temporärer Workaround bietet sich die Ausführung dieses Scripts an. Danach mussten einige Nutzer den Transport-Dienst oder sogar den Exchange-Server neu starten.


Alternativ lässt sich der nachfolgende PowerShell-Befehl einsetzen, um die Filterung der Mails temporär außer Kraft zu setzen:

Set-MalwareFilteringServer exch-19 -BypassFiltering $true

Auch hier muss der Transport-Dienst im Anschluss wohl neu gestartet werden. Ein weiterer Adminstrator hat mitgeteilt, dass nach Ausführung des Befehls

Get-TransportAgent "Malware Agent" | Disable-TransportAgent 

der Mail-Empfang und das Senden unter Exchange Server 2016 mit neuestem Cumulative Update auch wieder funktioniere. Microsoft hat einige Informationen zu diesem Themenfeld im Beitrag "Disable or bypass anti-malware scanning" zusammen getragen.

Im Blog des Autors gibt es inzwischen einen Nutzerkommentar, dass Microsoft bereits ein Signatur-Update zum Beheben des Problems freigegeben habe. 



Der Fehler betrifft Exchange Server 2013. 2016 und 2019.