Exkurs: Bugs. (Der erste Computer-Bug war eine Wanze!)

Vielmehr war es der Sage nach eine Motte, die sich 1947 in einem Computer der Sorte MARK II an der Harvard University verirrte und dort eine analoge Schaltung blockierte. Und es war die Computerspezialistin Grace Murray Hopper, welche die (reichlich lädierte) Motte aus dem Relais entfernte, in ein Album klebte und mit dem Hinweis versah, dies sei der ‘First actual case of bug’, der erste Fall eines Computer-Bugs. Seither gilt sie als einigen als „Entdeckerin der Computer-Bugs“, was natürlich Käse ist: Bugs gab es schon vorher, Miss Hopper fand bloß ein Insekt in ihrem, äh, “PC” ;-)
Hmm… Und warum wusste sie auf magische Weise, dass dies der “erste Fall” eines “Bugs” war, obwohl Gattungsbegriffe sich immer erst hinterher bilden? – Weil’s eine Sage ist. (Aber eine schöne.)

Die Website https://americanhistory.si.edu/ zeigt den ersten Bug

Computer Bug zu sehen auf https://americanhistory.si.edu/

Das regelmäßige Entfernen von Insekten, die von der Wärme der Computer angezogen wurden, deshalb in die Geräte krochen und dort Defekte verursachen, führte der Sage nach zum Begriff „debuggen“: Das „Entwanzen“ sollte störrischen Computern die Flausen austreiben. Noch heute heißen Programme, die zur Fehlerbereinigung in Software eingesetzt werden, „Debugger“. Selbst Windows (alle Versionen!) kennt einen Befehl namens Debug (Tastenkombination [Windows R], debug.exe eingeben), mit dem Sie direkt in Programm-Innereien herumstochern können, sofern Assembler Sie nicht schreckt.

Selbst in Windows 7 (32 Bit) noch drin: der Programm-Debugger debug.exe

Der Debugger ist allerdings auch eine Sicherheitslücke, der Viren zupass kommt oder zumindest kam: In der Vergangenheit gab es immer wieder Fälle, in denen sich digitale Erreger als Text oder in einem anderen “unschuldigen” Format in den PC schlichen und sich mit Hilfe von debug.exe selbst zu einem Virus umbauten (über den Umweg einer Batch-Datei, die Assembler-Quelltexte in Debug hineinpipete, aber das ist eine andere Geschichte und soll ein andermal erzählt werden).

Bugs sind auch heite an der Tagesordnung (siehe 2010/2016-Bug), problematisch für uns allerdings nur die Bugs, die eine ausnutzbare Sicherheitsschwachstelle darstellen – die “Exploits“.

Der PC – eine Mottenkiste

In der Steinzeit des PCs gab es nur eine Handvoll von Viren, dafür aber viele Bugs, und weil die Verkäufer das nicht zugeben wollten, wurde oft den Viren die Schuld gegeben (daher die vielen Viren-Mythen). (Anmerkung: Das kann ich natürlich nicht “wissenschaftlich nachweisen”, aber glauben Sie’s mir einfach trotzdem, ich kenne Händler, ich habe welche in der verwandtschaft.) Viren haben ihrerseits Programmierfehler und stürzen ab – den Unterschied zu einem “authentischen Windows-Fehler” – Made in Redmond – merkt keiner. Zumal frühe DOS-Viren oft recht blöde waren: Sie infizierten COM- und EXE-Dateien falsch oder zerstören diese beim Anstecken – die Folge waren weitere Abstürze, wiederum vermeintliche „Software-Bugs“.

Auch die Hardware spinnt gerne. Bei PCs bis etwa 2000 reichte schon eine einzige defekte ISA- oder PCI-Erweiterungskarte, um das ganze System durcheinander zu bringen, ebenso Wackelkontakte, typischerweise nach dem Umbau, oft auch durch Korrosion, Transport oder wärmebedingte Ausdehnungseffekte. Wer solche Fehler vermutet, sollte alle Karten und Stecker noch einmal prüfen. Wer mit seiner (alten) Hardware öfters Probleme hat, sollte geliebte Uralt-Karten würdevoll entsorgen und durch moderne Varianten ersetzen – das wirkt öfter Wunder, als man glauben möchte. (Glauben Sie mir: Ich kann ein Hardware-Museum aufmachen (ich habe sogar noch eine serielle ISA-Karte mit jumperbaren IRQs!), und (fast) jede neue Hardware war _wirklich_ besser als die alte.)

Bei modernen PCs sind es oft Probleme mit dem Netzteil, die für Probleme mit der Stabilität sorgen – Schuld ist meist die Gamer-Grafikkarte, die irrsinnig Saft zieht. Hinzu kommen Bugs im Design der Komponenten, in der Firmware (das ist die fest eingebaute Software, die zwischen Hardware und Betriebssystem vermittelt), im Treiber, im Betriebssystem (übrigens nicht nur in Windows) und natürlich in den Anwendungen selbst.

  • Programmierer packen Probleme manchmal falsch an oder berücksichtigen Veränderungen der Umgebung nicht hinreichend. Typisches Beispiel ist der Jahr-2000-Fehler: Ende der Siebziger glaubte niemand, den „IBM PC“ würde es länger als 10 Jahre geben. Ein etwas aktuelleres Pendant ist der 2010/2016-Bug, der sichtlich durch einen Umrechnungsfehler zwischen Hexadezimal- und Dezimal-System zustande kam.
  • Oft hat ein System „Architekturfehler“: Windows-Versionen vor XP mussten die Schwächen des antiken MS-DOS mit sich herumschleppen. Viele Tools dienten nur dazu, Probleme vorübergehend zu umgehen. Windows Vista litt ebenfalls daran, dass es bestimmte Dinger besser machen wollte, als es sie machen konnte.
  • Typische Bugs sind Endlosschleifen (das Programm hängt), Schreibzugriffe auf falsche Speicheradressen (damals unter Windows 3.1/9x ein Horror!), sowie Division-by-Zero-Fehler (man kann nicht durch 0 teilen; wenn ein Computer es versucht, kracht es im Chip-Gebälk) – und so weiter, und so fort.

Ein Großteil moderner Programme besteht aus Routinen, die der Fehlerbehandlung dienen: Fehler des Users, der Umgebung, des Programms selbst. Beispiel gefällig? Eine Anweisung, um einen Registry-Wert zu ändern, ist heute mit nur einer einzigen Zeile programmiert – aber vorher müssen Sie ja prüfen: “Kann ich (=die Software) überhaupt diesen Wert schreiben?” – “Existiert er womöglich schon?”; und hinterher müssen Sie prüfen: “Wurde der Wert geschrieben?”. Das zieht sich hin…

Es gibt Schätzungen, wonach ein Programmierer in 1000 Zeilen Code etwa fünf Fehler macht. Hält man sich dann vor Augen, dass schon ein altes Windows etwa 30 Millionen Zeilen Quellcode besteht, kann man sich die theoretische Zahl von Bugs vorstellen. (Diese Zahlen sind in dem Augenblick, da Sie sie lesen, schon wieder veraltet. Sie waren es schon, als ich sie schrieb.)

Bugs und Fehler sind weniger harmlos, als man denkt – wie diese Liste auf Wikipedia zeigt. Wir brauchen also keine Viren, der PC ist auch ohne sie schon ein verdammt unzuverlässiges “Schätz-Eisen”.

Der Computer HAL aus dem Film 2001 schiebt die Schuld allerdings auf den Anwender: „Das kann nur auf menschliches Versagen zurückzuführen sein.“. Support-Mitarbeiter können ein Lied davon singen: Wann immer die hören, dass “plötzlich” etwas nicht mehr geht, obwohl man gar nichts getan habe, können sie sicher sein, dass das Opfer des vermeintlichen Fehlers kurz zuvor etwas geändert hat. Und viele „Druckertreiberprobleme“ lassen sich – kein Witz! – dadurch lösen, dass der hochbezahlte Systemverwalter den Drucker einschaltet, den die Putzkolonne am Abend zuvor mit dem Wischtuch aus Versehen ausgeschaltet hatte.

“Ist das Gerät eingesteckt?” ist daher noch heute die Fehlerquellenbeseitigungsfrage #1.

Andreas Winterer

Andreas Winterer ist Journalist, Buchautor und Blogger und beschäftigt sich seit 1992 mit Sicherheitsthemen. Auf unsicherheitsblog.de will er digitale Aufklärung zu Sicherheitsthemen bieten – auf dem Niveau 'normaler Nutzer' und ohne falsche Paranoia. Auf der Nachbarseite passwortbibel.de geht's um Passwörter. Bitte kaufen Sie eines seiner Bücher.

Das könnte dich auch interessieren …