Wo programmiert wird, schleichen sich Fehler ein – aus Unkenntnis, Versehen, durch äußere Einflüsse oder kurzsichtige Planung. Die perfekte Rechenmaschine, den perfekten Computer mit mehreren Subsystemen wird es nicht geben. Diese Erkenntnis lehrt schon eines der ersten Computerprogramme überhaupt, geschrieben 1842 von Ada Lovelace für die geplante und nie gebaute analytische Rechenmaschine von Charles Babbage.
Bei diesem Bug handelt es sich um eine Verwechslung von Variablen: Wo „v5 / v4“ gedruckt ist, hätte „v4 / v5“ stehen müssen. Zur Entschuldigung von Ada Lovelace:
Es kann sich dabei auch schlicht um einen Setzerfehler handeln.
Frühe Käferkunde: Edisons Fehlersuche
Der Begriff „Bug“ für Fehler in der Entwicklung oder Ausführung kommt definitiv aus dem Ingenieurswesen und war schon Ende des 19. Jahrhunderts verbreitet. Das verraten die Aufzeichnungen von Thomas Alva Edison, der für Fehlfunktionen eines Telegrafiegeräts 1870 häufig das Wort „Bug“ in Briefen an Kollegen verwendete – auch schon mit einer Portion Humor.
So beginnt Edison schon mit einer fiktiven Klassifizierung der Bugs in Latein, wie es zur Beschreibung von Flora und Fauna üblich ist, und nennt einen späteren Bug „Callbellum“, der laut seinen Ausführungen in allen Apparaturen eines Telefons gute Lebensbedingungen fand.
Siehe auch: Die 10 gefährlichsten Viren im Jahr 2021
Harvard Mark II: Eingeklemmte Insekten
Auszug aus dem handschriftlichen Log des Mark II: Die diensthabenden Ingenieure machten sich einen Spaß daraus, die gefundene Motte in einem Relais für die Nachwelt aufzukleben.
IDG
Echte Insekten hatten es auf die Relais des Computers Harvard Mark II abgesehen, der 1947 unter der Ägide von Howard Aiken an der Harvard-Universität in Betrieb ging. Unter anderem arbeitete auch die Informatikpionierin Grace Hopper an der Programmierung des Mark II, welcher mit elektromagnetischen Hochgeschwindigkeitsrelais arbeitete. Einer der Ingenieure fand in einem der Relais eine eingeklemmte Motte, die Kontakte blockierte. Im handschriftlichen Log zum Betrieb des Mark II gibt es dazu einen eigenen Eintrag, der scherzhaft mit „erster echter Bug gefunden“ betitelt ist und die hinter Folie eingeklebte Motte enthält. Grace Hopper verwendete schon routinemäßig den Begriff „Debugging“ für die Fehlersuche in den frühen Großcomputern.
Kommafehler und falsche Einheiten
Die NASA fand nach dem katastrophalen Scheitern von Raumfahrtmissionen immer wieder vermeintlich banale Fehler in programmierten Abläufen als Ursache. 1962 musste der Satellit Mariner I kurz nach dem Start in einer herbeigeführten Explosion zerstört werden, nachdem die Trägerrakete vom Kurs abkam. Der Grund war eine fehlende Punktierung im Programmcode einer Steuereinheit, die die Mission scheitern ließ, welche damals rund 80 Millionen US-Dollar kostete (heute 630 Millionen).
Nicht minder schmerzhaft war 1999 der Verlust des Mars-Orbiters, nachdem die Ingenieure zur Berechnung der Flugdaten britische Maßeinheiten nutzten, die NASA diese aber metrisch interpretierte. Die Sonde kam dem Mars deshalb hundert Kilometer zu nah – oder waren es Meilen?
Datumsfehler: Jahr 2000 und Jahr 2038
Daten auf einer IBM-Lochkarte: Jedes Bit ist hier wertvoll und dies veranlasste eine unterdimensionierte Notation von Datumsangaben, die später zum Y2K-Bug führte.
IDG
Einer der berühmtesten Bugs, der überall große Aufmerksamkeit fand, war der Jahr-2000-Fehler (Y2K-Bug). Das Problem entstand schlicht aus einer verkürzten zweistelligen Schreibweise für Datumsfelder, nach der „00“ als das Jahr 1900 interpretiert wurde und nicht als 2000. Der Bug geht auf die Verwendung von Lochkarten zurück, auf welchen jedes Bit eine wertvolle Ressource war. Es kam ab 1998 Panik auf, dass es einen weltweiten Zusammenbruch von IT-Systemen geben könnte.
Dieser blieb weitgehend aus – jedoch nicht, weil der Bug harmlos war. Stattdessen setzten Regierungen groß angelegte Debugging-Aktionen an, die sich über Monate erstreckten. Im Jahr 2038 wird der zur Zeitrechnung verwendete 32-Bit-Integerwert auf Unix-Systemen überlaufen und in den negativen Bereich springen. Zur Vermeidung größerer Probleme in EDV-Systemen weltweit verlangt der Datumsbug auch wieder jetzt schon lang angelegte Lösungen. Der Linux-Kernel wurde zwischen Version 4.18 (2018) und 5.6 (2020) analysiert, um den 2038-Fehler in allen seinen Subsystemen zu beseitigen.
Lesetipp: Die aktuell 10 gefährlichsten Spam-Rufnummern
Meltdown und Spectre
Wohin übermäßige Ambitionen in der Entwicklung möglichst performanter Prozessoren führen, zeigen die weiterhin aktuellen Lücken Meltdown und Spectre. Diese setzten bei der Abarbeitung von Programmcode auf spekulative, vorausschauende Ausführung. Ein unerwünschter Nebeneffekt: Laufende Prozesse können damit Adressräume des Speichers lesen, auf die sie keinen Zugriff haben dürften. Die Entdecker der Lücken informierten Mitte 2017 die Hersteller betroffener CPUs. Anfang 2018 wurden diese CPU-Bugs öffentlich gemacht, die bis heute Fehlerbehebungen in Betriebssystemen und im nachladbaren Microcode von Prozessoren verlangen.
Das CVE-System: Kennung für Bugs
Die Menge an sicherheitskritischen Bugs über Betriebssysteme hinweg verlangt eine eindeutige Identifizierung. 1999 hat die US-Behörde NCF das Klassifikationssystem CVE (Common Vulnerabilities and Exposures) zur weltweiten Nomenklatur von Sicherheitslücken in Betrieb genommen. Dazu gehört auch die Einstufung von Schwere und Risiko. Sicherheitskritische Bugs in verbreiteter Software erhalten deshalb eine CVE-Nummer, wenn die Entdecker oder die Verantwortlichen einer Software diese beantragen. Der Bug „Heartbleed“ hat beispielsweise die ID CVE-2014-0160. Die CVE-Datenbank ist im Web unter https://www.cve.org öffentlich einsehbar.
Die schlimmsten Linux-Bugs
Die Entwicklungsweise des Linux-Kernels als Kooperation von bis zu 2000 Einzelentwicklern unter den wachsamen Augen von Linus Torvalds soll vor allem Bugs ausschließen.
Der Entwickler Eric Raymond formulierte dazu 1999 den Satz „Bei genügend Augenpaaren werden alle Bugs offensichtlich“ („Given enough eyeballs, all bugs are shallow“), der auch als das Linus-Gesetz bekannt wurde.
Fehlerfrei ist der Kernel nicht, denn diverse Subsysteme sind komplex und teilweise unterbesetzt. Dies führt immer wieder zu schweren Bugs in Linux-Systemen und im Kernel selbst. Die schlimmsten erhalten neben einer CVE-Klassifizierung griffige Namen und sogar Logos.
Heartbleed: Diese Sicherheitslücke, die Millionen Linux-Server betraf und viele Embedded-Systeme immer noch betrifft, hat 2014 ein unterbesetztes Open-Source-Projekt – Open SSL – ins Licht der Öffentlichkeit gerückt. Ein Programmierfehler plauderte Speicherinhalte eines Servers über eine SSL-Verbindung und die Heartbeat-Erweiterung von Open SSL aus. Heartbleed markierte den Start von großen Sicherheits- und Finanzierungsinitiativen für wichtige Open-Source-Projekte.
Shellshock: Die Lücken von 2015 in der Shell Bash erlauben es, an Umgebungsvariablen Funktionsdefinition mit Shell-Code anzuhängen. Brisant wurde die Lücken, weil sie sich unter bestimmten Umständen auf Webservern mit CGI-Scripts ausnutzen lassen, wenn diese die Bash aufrufen.
Dirty COW: 2017 wurde eine Sicherheitslücke im Kernel bekannt, die auf das Jahr 2007 zurückgeht. Diese Lücke betrifft eine Methode, über welche der Kernel Copy-on-Write-Aktionen (kurz „COW“) auf Dateien im Speicher durchführt. Schlimmstenfalls war ein root-Zugriff möglich.
Dirty Pipe: Anfang 2022 sorgte eine falsche Behandlung von Prozess-Pipes im Kernel ab Version 5.8 für Aufregung, die es gewöhnlichen Usern erlaubte, in fremde Dateien zu schreiben. Zusätzliche Brisanz hatte die Lücke, weil auch Android betroffen ist und viele ältere Android-Smartphones keine Systemupdates vom Hersteller mehr erhalten.
Autor: David Wolski
David Wolski schreibt hauptsächlich für die LinuxWelt und war vor langer Zeit im sagenumwobenen Praxis-Team der PC-WELT.