Es war eine äußerst unerfreuliche Entdeckung, die so mancher Systemadministrator da in der Nacht auf den 1. Jänner machen musste. Direkt zum Jahreswechsel hatten zahlreiche Exchange-Server die Auslieferung von Mails eingestellt. Stattdessen gab es eine wenig hilfreiche Fehlermeldung mit dem Text "Can't Convert '2201010001' to long".

Bugs, Bugs, Bugs

Im Verlauf der kommenden Stunden stellte sich dann langsam das heraus, was Microsoft nun offiziell bestätigt: Ein in seiner Trivialität für den Softwarehersteller geradezu verblüffender Fehler hatte dazu geführt, dass die Filterung der Mails nicht mehr funktionierte. Die eingehenden Nachrichten blieben so in der Warteschlange hängen, anstatt dass sie wie gewohnt zugestellt wurden.

Schnell setzte sich online der Name "Jahr 2022 Bug" für dieses Phänomen durch, dies in Anspielung auf den "Jahr 2000 Bug", vor dem dereinst viele zitterten. War doch damals unklar, ob alle Systeme den Wechsel auf ein neues Jahrtausend unbeschadet überstehen würden. Der Grund: Bei der ursprünglichen Programmierung wurde oft beim Platz gespart, für die Jahreszählung nur zwei Ziffern verwendet – womit dann auf das Jahr 99 das Jahr 00 folgte. Dank massiver Vorarbeiten in den Monaten zuvor, verlief der Wechsel ins Jahr 2000 schlussendlich aber – weitgehend – ohne größere Probleme.

Drum prüfe, wer vergleichen will

Ganz so trivial ist der aktuelle Fehler von Microsoft nun zwar nicht, er fällt aber in eine ähnliche Kategorie. Das Unternehmen selbst spricht von einem "Fehler bei der Datumsprüfung". Konkret löste die Versionsprüfung der Signaturdatei einen Absturz der Malware Engine aus, also jener Komponente, die die eingehenden Mails nach bekannter Schadsoftware durchsucht. Das aktuellste Signatur-Update – also mit Infos zu neuen Bedrohungen – trug nämlich eine Version, die für die bei der Versionsprüfung genutzte Variable schlicht zu groß war.

Dass dies just zum Jahreswechsel auftrat, liegt wiederum daran, dass die Versionsnummer vom Datum beginnend mit der Jahreszahl angeführt wurde. Nähere technische Details dazu wurden bereits in einem früheren Artikel dargelegt. Kurz gefasst hat Microsoft hier schlicht den falschen Datentyp (vorzeichenbehaftetes int32) für die zur Überprüfung genutzte Variable verwendet.

Auf Workaround folgt Workaround

Die Community hatte dabei auch recht schnell eine Lösung gefunden, damit die Mails wieder zugestellt werden: Die Deaktivierung der Malware-Engine des Exchange-Servers. Mit dieser geht natürlich ein erhöhtes Risiko für die Nutzer einher. Glücklicherweise kann Microsoft mittlerweile mit einem anderen Workaround aufwarten. Mithilfe eines zur Verfügung gestellten Skripts wird für die Versionsnummer der Signaturdatei schlicht das Jahr 2021 verlängert. So wird der 2. Jänner 2022 kurzerhand zum 33. Dezember 2021. Das mag zwar vom Kalender her Unsinn sein, für den Zweck der Versionsnummer ist das aber egal – und liefert eben bei der Prüfung keinen Fehler. Also zumindest bis es irgendwann einmal einen echten Bugfix gibt, an dem man bei Microsoft nach eigenen Angaben bereits arbeitet.

Neue Details

In dem Supporteintrag betont Microsoft auch, das entgegen bisherigen Annahmen nicht alle Exchange-Versionen betroffen sind, sondern "nur" Exchange Server 2016 und 2019. Zudem tritt der Fehler natürlich nur dort auf, wo auch die Malware-Engine aktiviert ist. Betont sei noch einmal, dass es hier immer um von Firmen selbst gehostete Systeme sowie hybride Lösungen geht. Die rein in der Cloud – also bei Microsoft 365 – betriebenen Mail-Systeme haben dieses Problem nicht. (Andreas Proschofsky, 2.1.2022)