Epochalypse Now – die Zeit für Y2K38 läuft

Millionen von IT-Systemen (auch Industriesysteme und IoT-Geräte) könnten ab dem 19. Januar mehr oder weniger große Probleme bereiten. Die Liste der möglichen Fehler ist lang: Störungen bei Kartenzahlungen, Fehlalarme in Sicherheitssystemen, Betriebsstörungen bei medizinischen Geräten, Ausfälle automatisierter Beleuchtungs-, Heizungs- und Wasserversorgungssysteme sowie eine ganze Reihe eher harmloser Fehler. Um genau zu sein: Das kritische Datum ist der 19. Januar 2038. Zukunftsmusik? Durchaus nicht. In manchen Fällen könnte die Zeit zur Behebung bereits knapp sein. Der Grund dieser Probleme ist eine Ganzzahl, die Datum und Uhrzeit speichert und die an diesem Datum überläuft. Obwohl die Fehlerursache relativ klar ist, erfordert die Behebung umfassende und systematische Maßnahmen auf mehreren Ebenen – Regierungen, internationale Organisationen, Unternehmen und Privatpersonen müssen reagieren.

Der ungeschriebene Standard der Unix-Epoche

Die Unix-Epoche (auch Unixzeit genannt) ist eine Zeitdefinition, die in Unix-Betriebssystemen verwendet und auch in anderen Bereichen der IT-Branche eingesetzt wird. Dabei werden die Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC gezählt. Jeder beliebige Zeitpunkt wird als Anzahl der Sekunden angegeben, die seit diesem „Nullpunkt“ vergangen sind. Für Daten vor 1970 dienen negative Werte. Dieses Prinzip ist einfach. Darum wurde es von den Unix-Entwicklern gewählt. Anstatt Jahr, Monat, Tag und Uhrzeit einzeln zu speichern, genügt eine einzige Zahl. Dies vereinfacht viele Operationen, z. B. das Berechnen von Zeitintervallen oder das Sortieren. Heutzutage wird die Unix-Epoche nicht nur in Unix-Systemen genutzt, sondern auch in Datenbanken, Programmiersprachen, Netzwerkprotokollen sowie auf iOS- und Android-Smartphones.

Die Y2K38-Zeitbombe

Bei der Entwicklung von Unix wurde die Zeit als 32-Bit-Ganzzahl mit Vorzeichen definiert. Auf diese Weise lässt sich ein Datumsbereich von 1901 bis 2038 darstellen. Das Problem ist, dass diese Zahl am Dienstag, den 19. Januar 2038 um 03:14:07 UTC ihren Maximalwert (2.147.483.647 Sekunden) erreicht. Dann läuft der Zähler über, der Wert wird negativ, und betroffene Geräte werden vom Januar 2038 zum 13. Dezember 1901 „teleportiert“. In einigen Fällen kann die Zeitreise etwas kürzer sein und führt zurück ins Jahr 1970.

Dieses Ereignis hat verschiedene Namen: Jahr-2038-Problem, Epochalypse und Y2K38. Es könnte zu Ausfällen in Systemen führen, die weiterhin die 32-Bit-Zeitdarstellung verwenden: von Verkaufsterminals, eingebetteten Systemen und Routern bis zu Fahrzeugen und Industrieanlagen. Moderne Systeme sind nicht betroffen, da sie die Zeit mit 64 Bit speichern. Dadurch erweitert sich der Datumsbereich auf Hunderte Milliarden von Jahren in die Zukunft. Nach wie vor sind aber noch Millionen von Geräten mit 32-Bit-Zeitsystem in Betrieb und müssen vor dem „Tag Y“ aktualisiert oder ersetzt werden.

In diesem Kontext ist mit 32-Bit und 64-Bit das Format gemeint, in dem das Datum gespeichert wird. Wenn Betriebssystem oder Prozessor die Angabe 32-Bit oder 64-Bit enthalten, bedeutet dies nicht automatisch, dass das Datum im „nativen“ Bit-Format gespeichert wird. Darüber hinaus speichern viele Programme das Datum auf ganz andere Weise und können unabhängig von ihrer Bit-Größe gegen das Y2K38-Problem immun sein.

In einigen Fällen, in denen keine Datumsangaben vor 1970 verarbeitet werden müssen, wird das Datum als vorzeichenlose 32-Bit-Ganzzahl gespeichert. Dieser Zahlentyp kann ein Datum von 1970 bis 2106 darstellen, womit das Problem etwas weiter in der Zukunft liegt.

Unterschiede zum Jahr-2000-Problem

Das berüchtigte Jahr-2000-Problem (Y2K) am Ende des 20. Jahrhunderts hatte gewisse Ähnlichkeiten mit Y2K38: Systeme, die das Jahr nur zweistellig speicherten, konnten leicht die Jahrhunderte verwechseln. Experten und Medien befürchteten damals eine digitale Apokalypse. Es gab jedoch nur viele vereinzelte Vorfälle. Eine globale Katastrophe blieb aus.

Der wichtigste Unterschied zwischen Y2K38 und Y2K ist der Umfang, in dem unser Leben inzwischen digitalisiert ist. Die Anzahl der Systeme, die aktualisiert werden müssen, liegt weit über der Anzahl der Computer, die es im 20. Jahrhundert gab. Und die Aufgaben und Prozesse, die täglich von Computern verwaltet werden, sind überhaupt unermesslich. In „normalen“ Computern und Betriebssystemen wurde das Y2K38-Problem bereits durch simple Software-Updates behoben oder solche Lösungen sind geplant. Anders ist es bei Mikrocomputern, die Klimaanlagen, Aufzüge, Pumpen, Türschlösser und Fließbänder steuern. Dort könnten veraltete, Y2K38-anfällige Softwareversionen sehr wohl noch im nächsten Jahrzehnt aktiv sein.

Mögliche Probleme der Epochalypse

Eine Verschiebung des Datums auf 1901 oder 1970 kann je nach System unterschiedliche Folgen haben. In einigen Fällen kann es überhaupt unbemerkt bleiben. Beispielsweise bei einem System, das jeden Tag um 19:00 Uhr die Beleuchtung einschaltet. In anderen Systemen, die mit einem vollständigen und genauen Zeitstempel funktionieren, könnte es zu einem kompletten Ausfall kommen. Beispiel aus dem Jahr 2000: Zahlungsterminals und Drehkreuze im öffentlichen Nahverkehr versagten den Dienst. Auch kuriose Fälle sind vorstellbar, z. B. könnte eine Geburtsurkunde auf das Jahr 1901 ausgestellt werden. Weitaus schlimmer wäre der Ausfall kritischer Systeme, beispielsweise Störungen in Heizungsanlagen oder Zwischenfälle im System zur Knochenmarkanalyse in einem Krankenhaus.

Die Kryptografie spielt bei der Epochalypse eine eigene Rolle. Ein weiterer entscheidender Unterschied zwischen 2038 und 2000 ist, dass Verschlüsselung und digitale Signaturen inzwischen in der gesamten Kommunikation eingesetzt werden. Wenn das Datum auf einem Gerät nicht stimmt, schlägt die Überprüfung von Sicherheitszertifikaten gewöhnlich fehl. Ein anfälliges Gerät wäre also weitgehend von der Kommunikation abgeschnitten, auch wenn die entsprechenden Unternehmensanwendungen keinen Code enthalten, der das Datum fehlerhaft verarbeitet.

Die Reichweite der möglichen Folgen lässt sich leider nur durch kontrollierte Tests aller Systeme ermitteln. Kaskadenrisiken müssen dabei separat analysiert werden.

Bösartige Y2K38-Szenarien

IT- und InfoSec-Teams sollten Y2K38 nicht als einfachen Programmfehler betrachten, sondern als Schwachstelle, die zu verschiedensten Fehlern führen kann, bis zum Denial-of-Service. In einigen Fällen kann Y2K38 sogar von Angreifern ausgenutzt werden. Dazu benötigen diese eine Möglichkeit, die Zeit auf dem Zielsystem zu manipulieren. Dies ist in mindestens zwei Szenarien möglich:

• Eingriff in die Daten des NTP-Protokolls: Dem angegriffenen System wird ein gefälschter Zeitserver untergeschoben
• Fälschung des GPS-Signals, wenn das System auf Satellitenzeit angewiesen ist

Am wahrscheinlichsten sind solche Exploits in OT- und IoT-Systemen. Dort werden Schwachstellen naturgemäß langsamer gepatcht und die Folgen von Ausfällen können gravierend sein.

Ein Beispiel für eine Schwachstelle, bei der die Zeitzählung leicht ausgenutzt werden kann, ist CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8). Sie betrifft Konsolen zur automatischen Tankanzeige (Modell Dover ProGauge MagLink LX4). Die Zeitmanipulation kann dazu führen, dass das Gerät an Tankstellen abgelehnt wird und der Zugriff auf die Online-Verwaltungsfunktionen ausfällt. Dieses Problem hat einen eigenen CISA-Eintrag.

Aktueller Stand der Y2K38-Gegenmaßnahmen

Die Grundlagen für eine Lösung des Y2K38-Problems wurden im Jahr 2000 für die wichtigsten Betriebssysteme gelegt. Der Linux-Kernel unterstützt die 64-Bit-Zeit ab Version 5.6 (seit dem Jahr 2020) auch für 32-Bit-Architekturen. Für 64-Bit-Linux ist das Problem nicht relevant. Die BSD-Familie, macOS und iOS verwenden auf allen modernen Geräten die 64-Bit-Zeit. Alle im 21. Jahrhundert veröffentlichten Windows-Versionen sind nicht von Y2K38 betroffen.

Weitaus komplexer ist die Situation in den Bereichen Datenspeicher und Anwendungen. Moderne Dateisysteme (z. B. ZFS, F2FS, NTFS und ReFS) wurden mit 64-Bit-Zeitstempeln konzipiert, während ältere Systeme (ext2 und ext3) Schwachstellen aufweisen. Für ext4 und XFS müssen bestimmte Flags aktiviert werden (extended inode für ext4 bzw. bigtime für XFS), und sie erfordern möglicherweise die Offline-Konvertierung vorhandener Dateisysteme. In den Protokollen NFSv2 und NFSv3 bleibt das veraltete Zeitspeicherformat bestehen. Bei Datenbanken ist es ähnlich: Der Typ TIMESTAMP in MySQL ist grundsätzlich auf das Jahr 2038 beschränkt und erfordert eine Migration auf DATETIME. In PostgreSQL sind die standardmäßigen Zeitstempeltypen dagegen sicher. Für in C geschriebene Anwendungen gibt es Pfade, um die 64-Bit-Zeit auch in 32-Bit-Architekturen einzusetzen. Jedoch müssen alle Projekte neu kompiliert werden. Sprachen wie Java, Python und Go verwenden normalerweise Typen, die einen Überlauf vermeiden. Ob kompilierte Projekte sicher sind, hängt aber davon ab, ob sie mit schwachstellenbehafteten Bibliotheken in C interagieren.

Eine riesige Zahl von 32-Bit-Systemen, eingebetteten Geräten und Anwendungen bleibt anfällig. Der Weg ist lang: Behebung der Probleme, Testen der neuen Versionen und Installation der Updates durch alle Nutzer.

Verschiedene Organisationen und Enthusiasten versuchen, die entsprechenden Informationen zu systematisieren. Leider sind diese Ansätze alles andere als einheitlich. So etwas wie eine „zentrale Datenbank für Y2K38-Schwachstellen“ gibt es nicht (1, 2, 3, 4, 5).

Ansätze zur Behebung von Y2K38

Die Methoden, die zur Priorisierung und Behebung von Schwachstellen entwickelt wurden, lassen sich direkt auf das Jahr-2038-Problem anwenden. Die größte Herausforderung: Es gibt bisher kein Tool, um eine vollständige Liste der Software- und Hardware-Schwachstellen zu erstellen. Daher sind zuerst die folgenden Schritte notwendig: Die Inventarisierung der Unternehmens-IT-Assets wird aktualisiert, wobei detaillierte Informationen über Firmware und installierte Software berücksichtigt werden. Anschließend erfolgt eine systematische Untersuchung der Schwachstellen.

Wichtig bei der Priorisierung von Assets sind die Bedeutung der Unternehmenssysteme und die Daten über den technologischen Ansatz, auf dem die einzelnen Systeme basieren. Weitere Schritte: Studium des Support-Portals des Herstellers und direkte Anfragen an die Hardware- und Softwarehersteller nach ihrem Y2K38-Status. Im Extremfall müssen Tests gefahren werden.

Beim Testen von Unternehmenssystemen sind besondere Vorsichtsmaßnahmen erforderlich:

• Systeme, die direkt mit der Produktion zusammenhängen, sind von Tests ausgeschlossen.
• Erstelle unmittelbar vor dem Testen ein Backup.
• Isoliere das zu testende System, damit es andere Unternehmenssysteme nicht durcheinanderbringt.
• Wenn NTP oder GPS für die Datumsänderung verwendet wird, muss sichergestellt werden, dass die 2038-Testsignale keine anderen Systeme erreichen können.
• Nach dem Testen müssen die Systeme wieder auf die richtige Zeit eingestellt werden. Das Testverhalten der Systeme wird gründlich dokumentiert.

Wenn sich herausstellt, dass ein System für Y2K38 anfällig ist, sollte beim Hersteller ein Behebungszeitplan angefordert werden. Wenn es keine Lösung gibt, steht eine Migration an. Glücklicherweise ist noch genügend Zeit, um auch relativ komplexe und teure Systeme zu aktualisieren.

Wichtig! Y2K38 ist kein Problem der fernen Zukunft, das noch fünf oder sogar acht Jahre warten kann. Es ist wahrscheinlich, dass bereits zu wenig Zeit ist, um den Fehler vollständig zu beheben. Für ein Unternehmen und seine technologische Ausrüstung gilt jedoch: Durch sorgfältige Planung und einen systematischen Ansatz lässt sich das Problem rechtz