[English]Noch eine kurze Meldung für Administratoren von Splunk-Produkten. Da droht zum 1.1.2020 ein Funktionsausfall, ähnlich wie beim Year 2K-Problem zur Jahrtausendwende, weil Zähler an diesem Datum überlaufen. Es gibt aber Patches, um dieses Problem zu beheben.
Ich bin bereits vor einigen Stunden bei Bleeping Computer auf das Thema aufmerksam geworden. Der nachfolgende Tweet weist aber nochmals auf das Problem hin.
Einige Splunk-Plattformen sind von einem Fehler bedroht, der am 1. Januar 2020 in Aktion tritt und dem berüchtigten Y2K-Bug ähnelt – Patchen sehr zu empfehlen https://t.co/J451iUTLE3 ^RW
— Trend Micro Deutschland (@TrendMicroDE) November 27, 2019
Splunk ist ein Log-, Monitoring- und Reporting-Tool, das Maschinendaten (Logs, Metriken und weitere Daten von Applikationen, Servern und Netzwerkgeräten) indiziert und sie über ein durchsuchbares Repository für alle Benutzer zugänglich und nutzbar macht. So lassen sich Grafiken, Reports und Warnmeldungen generieren. Systemadministratoren sollen so Störfälle erkennen und analysieren können.
Das Problem: Inkonsistente Datentypen
Vom Splunk-Eingabeprozessor werden verschiedene Arten von Daten und Zeitstempeln, basierend auf der Datei ‚datetime.xml‘ verwendet. Die XML-Datei verwendet reguläre Ausdrücke, um die Informationen aus eingehenden Daten zu extrahieren. Das Problem ist, dass die ungepatchte Version der Datei Jahresangaben im zweistelligen Datumsformat bis 2019 extrahieren kann. Das bedeutet, dass die betroffenen Splunk-Anwendungen nur bis zum 31. Dezember 2019 funktionieren.
Die Release-Notes für Splunk Enterprise gibt an, dass ab dem 1.1.2020 veraltete Splunk-Instanzen „eingehende Daten fälschlicherweise als ungültiges Zeitstempeljahr behandeln”. Sie könnten entweder Zeitstempel mit dem aktuellen Jahr hinzufügen oder das Datum falsch interpretieren und einen Zeitstempel mit dem falsch interpretierten Datum hinzufügen. In der Splunk Enterprise-Dokumentation wird daher gewarnt, dass ein Update vor dem 1. Januar 2020 installiert werden muss, damit die Plattform Zeitstempel für Ereignisse mit einem zweistelligen Jahr auch nach dem Jahreswechsel korrekt erkennt.
Betroffene Splunk-Produkte
Die Release-Notes des Herstellers listen die nachfolgenden Splunk-Produkte als vom Fehler betroffen auf. Administratoren sollten diese Produkte, unabhängig vom zugrunde liegenden Betriebssystem, patchen.
- Splunk Cloud
- Splunk Light
- Splunk Enterprise
- Indexers, clustered oder nicht
- Heavy forwarders
- Search heads, clustered oder nicht
- Search head deployers
- Deployment servers
- Cluster masters
- License masters
Splunk Universal Forwarder sind unter den folgenden Bedingungen betroffen:
- Wenn sie strukturierte Daten wie CSV-Dateien (Comma Separated Values) verarbeiten, mit der Einstellung INDEXED_EXTRACTIONS in ‚props.conf‘.
- When they process data inputs prior to forwarding, with the ‚force_local_processing = true‘ setting in ‚props.conf‘
Splunk Cloud-Kunden erhalten den Fix automatisch. Splunk Cloud-Kunden werden von Support-Mitarbeitern informiert, wann das Upgrade stattfindet. Da es sich um ein kritisches Update handelt, gibt es keine Möglichkeit, dieses zu verschieben. Weitere Details sind im Bedarfsfall den Release Notes zu entnehmen.
Das ist nicht nur „ähnlich wie beim Y2K-Problem“, das dürfte eine direkte Folge davon sein.
Damit möglichst wenig geändert werden musste und auch zweistellige Jahresangaben weiter funktionieren wurde einfach eine Zwischenschicht eingebaut. Die prüft dann, ob die zweistellige Zahl unter einem Schwellwert ist und hängt ggf. „20“ vornedran. Damals wurde als Schwellwert gerne „20“ genommen, denn“20 Jahre in die Zukunft reicht ja“. Also „19“ = „2019“, „20“=“1920″. Wenn es nie angepasst wurde rächt sich das nun – genau jetzt.
Win10 hat übrigens inzwischen 2050 als Schwellwert (tief versteckt in den Kalendereinstellungen: „eine zweistellige Jahreszahl wird interpretiert als Jahr zwischen“ (1950 und 2049)).
Ich bin gespannt, welche Software sonst noch seit 1999 in diesem Punkt nicht mehr angefasst wurde.
Ich muss mich partiell korrigieren: in diesem Fall ist es noch wahnsinniger. Splunk nimmt zur Analyse tatsächlich Regex. Hier im einfachsten Fall:
(20\d\d|19\d\d|[901]\d(?!\d)) – also ‚vierstellige Zahl, beginnend mit „20“ ODER vierstellige Zahl, beginnend mit „19“ ODER zweistellige Zahl, beginnend mit „9“,“0″ oder „1“‚. Die „Lösung“: die zweistellige Zahl darf jetzt auch mit einer „2“ beginnen…
Ich nehme noch Wetten an, ob bis in zehn Jahren einfach eine „3“ mit eingefügt oder das bis dahin anständig implementiert wird :-)