Erste Erkenntnisse aus Log4Shell

Seit etwas mehr als einer Woche brennt das Netz. Um den 10. Dezember herum mehrten sich Berichte über eine bis dahin völlig unterschätzte Standardkomponente vieler Serveranwendungen. Niemand hatte damit gerechnet, dass von einer Bibliothek, deren Aufgabe im geordneten Schreiben von Protokolldateien besteht, eine ernsthafte Gefahr ausgehen könnte. Diese Gefahr war allerdings nicht nur ernsthaft, sie lag in ihrer Bedrohlichkeit irgendwo zwischen einem knapp an der Erde vorbeirauschenden Meteoriten von der Größe der Cheopspyramide und der Wiederankunft Godzillas. Anders gesagt: Wenn ein Computerfehler es bis in die ARD-Tagesthemen schafft, sollten Sie sich mit Vorräten eindecken und die Haustür verrammeln.

Es ist auch nicht so, als habe sich im Lauf der vergangenen Woche die Lage wesentlich gebessert. Inzwischen müssen wir zum dritten Mal unsere Server patchen, weil sich die bislang ergriffenen Gegenmaßnahmen als unzureichend entpuppt haben. Ich möchte nicht darauf wetten, dass wir bis Weihnachten mit dem Abdichten durch sind.

Die Lage bleibt also interessant. Dennoch können wir jetzt schon erste Schlüsse ziehen. Kristian Köhntopp merkt an, bei Log4Shell handle es sich nicht etwa um einen Fehler, sondern eigentlich funktioniere die Bibliothek genau wie vorgesehen. Adriana Groh bemängelt, wie eine komplette Industrie sich bei der Open-Source-Community mit Gratissoftware eindeckt, mit ihr Millionengewinne scheffelt, nicht im Traum auf die Idee kommt, die oft in Selbstausbeutung betriebenen Projekte personell oder wenigstsens finanziell zu unterstützen, aber laut herumjammert, wenn in der Software Fehler auftauchen. In der Liga dieser beiden Autorinnen spiele ich längst nicht, aber immerhin bin ich lang genug um Geschäft, um zwei Beobachtungen organisatorischer Art beisteuern zu können.

Die allererste Frage ist ein simples

Warum?

Diese Sicherheitslücke ist die überflüssigste der vergangenen zehn Jahre, vielleicht sogar mehr, und an gefährlichen Lücken herrschte wahrlich kein Mangel. Bei allen mir bekanntgewordenen Lücken konnte ich aber zumindest verstehen, warum jemand so etwas haben will. Nehmen wir Spectre und Meltdown, zwei verwandte Lücken, deren Ursprung im zutiefst sinnvollen Mechanismus moderner Prozessoren liegt, den kommenden Programmablauf vorhersehen und schon einmal vorbereiten zu können, damit es dann später schneller geht. Dass sich diese vorbereitenden Maßnahmen missbrauchen lassen, um ansonsten unzugängliche Speicherbereiche auszulesen, war nicht klar, und ich werfe niemandem vor, das nicht geahnt zu haben. Bei Log4Shell aber sei die Frage erlaubt: “Welcher bekiffte Schimpanse war auf die komplett idiotische Idee gekommen, einem Mechanismus, dessen einziger Anwendungszweck im stumpfen Schreiben von Protokolldateien besteht, eine Funktion zum Codenachladen von externen Seiten einzubauen? Ich administriere seit 20 Jahren Java-Applikationen, seit 35 Jahren verdiene ich Geld in der IT, zeitweise in der Entwicklung, zeitweise in der Administration. Ich habe keinen einzigen Fall erlebt, in dem die sich hier als verwundbar herausstellende Funktion Sinn ergeben hätte. Log4Shell ist ein klassischer Fall von Featureitis, dem blindwütigen Einbau von Funktionen, um ein Programm noch mächtiger werden zu lassen – ohne sich die Frage zu stellen, ob es da draußen auch nur eine Seele gibt, die das braucht. Es ist wie die Star-Wars-Sequels: interessante Idee, leider grauenhaft ausgeführt, und am Ende wären wir alle glücklicher gewesen, hätte es sie nie gegeben.

Die Stunde der Häkchensetzer

Im Jahr 2013 schrieb der US-amerikanische Anthropologe David Graeber seinen Aufsatz über Bullshit-Jobs. Er unterscheidet dabei fünf Typen: Lakaien, Auftragsschläger, Hinterherflicker, Häkchensetzer und Aufgabenverteiler. All diesen Aufgaben ist gemein, zutiefst überflüssig zu sein. Im Prinzip ließen sich anhand Log4Shell alle fünf Typen aufzählen. Besonders die letzten drei sind offensichtlich: Aufgabenverteiler finden sich häufig in Projektleitungspositionen wieder und haben vor allem die Aufgabe, Leute durch die Gegend zu scheuchen, die auch ohne sie wissen, was sie zu erledigen haben, ohne dabei selbst reale Arbeit zu leisten. im Rahmen von Log4Shell haben sie nicht nur die offensichtlichen Aufgaben an die offensichtlich Zuständigen verteilt, sondern auch noch jede Menge Overhead in Form von Meetings und Task Forces erzeugt, in denen sie stundenlang auf ihre Aufgabenlisten gestarrt und Leute unter Druck gesetzt haben. Den Druck abbekommen haben im Wesentlichen die Hinterherflicker, die in aller Eile versuchten, die Sicherheitslücke zu schließen. Dagegen ist an sich nichts zu sagen, trotzdem wäre ihre Aufgabe überflüssig, wenn vorher Andere ihre Arbeit ordentlich erledigt hätten. Noch einmal: Wessen Idee war die Funktion mit den Remote-Aufrufen?

Wer jetzt aber besonders aufblüht, ist der Häkchensetzer. Dessen Aufgabe ist mit der Bezeichnung schon komplett beschrieben: Häkchen setzen. Als die ersten Log4Shell-Berichte auftauchten und die Leute unten im Maschinenraum nervös in Richtung ihrer Server schielten, weil anders als ihren Vorgesetzten sofort das Ausmaß der Krise klar war, hielten die Häkchensetzer noch Winterschlaf, Dann aber, als jemand das Problem in Babysprache übersetzt und damit selbst für BWLer verständlich dargestellt hatte, wurden die Häkchensetzer aktiv und klimperten mit Excel herum. Lange Tabellen schrieben sie zusammen mit Servernamen, Projektkennungen, Verantwortlichen und vor allem: Feldern zum Ankreuzen. Am Montag schickten sie diese Version herum, in der sie alle Server blind auf Rot gesetzt hatten und verlangten, in das dritte Feld ein Häkchen zu setzen, dass die Lücke gestopft sei. Ein ganzer Teil der Server stand völlig unberechtigt auf der Liste, weil darauf nicht einmal Java installiert war, woran sich schon ablesen ließ, wie wenig Verständnis in ihr steckte. Deswegen gab es am Dienstag eine erweiterte Version mit einer Spalte, in der stand, ob ein Scanner auf dem Server eine verwundbare Log4j-Version gefunden hatte. Wo die Datei gefunden wurde, behielt die Liste für sich, denn sonst hätte jemand gezielt das Problem beseitigen können. Ich weiß, es gibt Argumente für solche Geheimniskrämerei. Insbesondere könnte bei der Suche nach der Lücke noch eine weitere, vom Scan bislang noch nicht erfasste gefunden und bei dieser Gelegenheit gleich mit repariert werden, doch so weit denken Häkchensetzer nicht. Im Gegenteil. Bis zum Ende der Woche wuchs die Liste um weitere zwei Spalten auf insgesamt drei Scanergebnisse an, bei denen drei unterschiedliche Teams zu verschiedenen Ergebnissen gekommen waren und in keinem Fall darlegten, was genau sie gefunden hatten. Geblieben war in jedem Fall die letzte Spalte – die mit dem Häkchen, und jetzt zeigt sich die gesamte Misere hinter diesem Vorgehen: Mit jeder neuen Version waren die Häkchen wieder gelöscht worden – natürlich, immerhin gab es ja neue Erkenntnisse. Mit jeder neuen Version bauten die Häkchensetzer wieder Druck auf und verlangten, die Liste erneut auszufüllen. Wer brav sein Häkchen setzte, hatte Ruhe. Wer es nicht setzte, musste sich in stundenlangen Krisensitzungen rechtfertigen, wann endlich damit zu rechnen sei. Wohlgemerkt: Niemand interessiert sich dafür, dass die Lücke geschlossen wird. Es geht allein darum, Häkchen zu setzen – was dazu führte, dass die Leute genau das taten. Sollte wider Erwarten jemand mitbekommen, dass sie sich auf ihren Servern nicht einmal eingeloggt hatten, können sie immer noch behaupten, sie hätten irgendwas repariert, aber offenbar nicht das, worum es in den Listen ging. Wie auch, wenn niemand sagt, wo der Fehler liegen soll?

Es geht ums Häkchensetzen, nicht ums Problemvestehen. Deswegen haben die Häkchensetzer auch nur Mechanismen ausgearbeitet, die verwundbaren Bibliotheken der 2.x-Reihe zu finden. Dass es auch eine Version 1.x gibt, deren Sicherheitslücken seit inzwischen sechs Jahren nicht mehr geflickt werden, geht komplett an ihnen vorbei. Dass Log4j auch auf Maschinen herumliegen kann, auf denen keine Java-Umgebung installiert ist, weswegen hier keine besondere Gefahr herrscht, interessiert sie nicht. Dass es Javaprogramme mit Log4j gibt, die üblicherweise nicht laufen, nur zu bestimmten Anlässen lokal von den Admins ausgeführt werden und darum auch keine extern ausnutzbare Schwachstelle vorliegt, verstehen sie nicht. Dass es managed Server gibt, auf denen nur die Systemadministration bestimmte Dateien austauschen kann und die angeschriebenen Applikationsteams keine Möglichkeit dazu haben, ignorieren sie. Vor zwei Jahrzehnten stolperte ich erstmals über die Satire, die behauptete, Manager glaubten, tote Pferde reiten zu können, indem sie eine größere Peitsche kauften. Seit zwei Jahrzehnten versuche ich vergeblich, Managern zu erklären, der Text sei witzig gemeint, keine Handlungsanweisung.

Während des zweiten Weltkriegs beobachteten die Bewohner Melanesiens, wie Soldaten auf ihren Inseln Basen errichteten und daraufhin Versorgungsflugzeuge Güter an Fallschirmen abwarfen. Mit dem Ende des Kriegs verschwanden die Soldaten und mit ihnen die Versorgungsflugzeuge. Was lag aus Sicht der Inselbewohner näher, als diesen Gottheiten Statuen in Form von Flughafentürmen und aus Holzgeflecht nachgebauten Flugzeugen zu errichten, um sie wieder zum Abwurf von Versorgungsgütern zu bewegen? Wir nennen uns aufgeklärt, spotten über die so genannten “Cargo-Kulte“, weil sie offensichtlich Ursache und Wirkung verwechseln, aber in unseren Managementetagen praktizieren wir genau das. Statt zu begreifen, dass wir unsere Server in Ordnung bringen müssen und als Ergebnis danach unsere Listen abhaken können, verbringen wir täglich Stunden in Telefonkonferenzen, in denen wir diskutieren, warum in unseren Listen noch Häkchen fehlen und glauben, dass hierdurch auf magische Weise die Sicherheitslücken unserer Server geflickt werden. Deswegen sind Häkchensetzer nicht einfach nur überflüssig oder lästig. Sie sind gefährlich, weil sie ein Klima schaffen, in dem es Vorteile bringt, Leute anzulügen, um sie schnell loszuwerden, anstatt sich in Ruhe hinzusetzen und das eigentliche Problem zu beseitigen. Wer langsam und sorgfältig arbeitet, riskiert, irgendwelche Ticketlaufzeiten zu reißen und seinen Jahresbonus gekürzt zu bekommen. Wer einfach nur das Ticket schließt, riskiert schlimmstenfalls, dass jemand den Schwindel bemerkt. Uppsie, mein Fehler, da muss ich wohl ein neues Ticket öffnen. Ärger bekomme ich dafür nicht, sondern nur, wenn ich zu lange dran sitze.

Kein IT-spezifisches Problem

Jetzt fragen Sie bitte noch einmal, warum unser Dienstleistungssektor so schlecht ist. Weil es nicht nur in der IT ums Häkchensetzen geht. Nehmen Sie die Corona-Infektionszahlen. Städte müssen befürchten, dass ihre Geschäfte, Hotels und Gaststätten geschlossen werden, wenn sie zu hohe Zahlen melden. Jetzt gäbe es zwei Möglichkeiten, der Sache zu begegnen: entweder Maßnahmen zur Pandemieeindämmung ergreifen, es sich mit Einzelhändlerinnen, Schankwirtinnen, Hoteliers und nicht zuletzt genervten Konsumentinnen verscherzen oder – huch – sich beim Melden der Zahlen ein itze-klitze-kleines Bisschen zu verrechnen. Sollte wider Erwarten jemand von der Sache Wind bekommen erzählen die Verantwortlichen einfach, “jeweils ein falscher Datensatz habe zwei Datensätze komplett zerstört”. Wer kennt das nicht? Passiert mir auch jeden Tag.

Feldmarschall Potemkin mag eine gute Idee sein, um lästige Fragesteller loszuwerden. Er funktioniert dann nicht, wenn sich einer dieser Plagegeister unerwartet für seine Arbeit interessiert. Vor allem aber löst er keine Probleme, er schiebt sie nur auf und lässt sie weiter wachsen. Irgendwann erwischt uns die Realität, und dann rettet uns kein Excel-Sheet mehr.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.