Die (aussichtslose) Schlacht gegen Software-Fehler

18. November 2005, 10:26
33 Postings

Die Geschichte der Bugs wiederholt sich ständig - Werden die Entwickler nicht klüger oder ist es wirklich ein Kampf gegen Windmühlen?

Im Magazin Wired ist der zweite Teil eines Specials zum Thema Software-Bugs erschienen, der WebStandard berichtete bereits von Teil eins, siehe Die schwersten Software-Fehler in der Geschichte. Diesmal geht es um die Frage, ob sich Software-Fehler - so genannte "Bugs" - überhaupt verhindern lassen und wie sich die Geschichte der Fehler scheinbar immer wiederholt.

Eine Geschichte voller Fehler

Im Jahr 1976 meinte der niederländische Computerpionier Edsger Wybe Dijkstra, dass das Testen von Programmen ein effektives Mittel zum Beweisen von Bugs, aber hoffnungslos ungeeignet um deren Fehlen zu belegen, sei. Gute dreißig Jahre später zeigt sich wie recht der mittlerweile verstorbene Informatiker hatte. Alle Softwarefirmen - von Microsoft über Apple und Oracle bis hin zu Mozilla und SuSE haben mit Fehlern in ihren Produkten zu kämpfen. Auch wiederholt sich die Geschichte immerzu; so wurden erst kürzlich wieder zahlreiche Lücken geschlossen, die "Buffer Overflow"-Attacken ermöglichten. Diese Lücken sind seit 1988 - mit dem Auftreten des ersten Internet-Wurms bekannt, doch scheinen es Programmierer und Architekten nicht zu schaffen aus Fehlern zu lernen - oder doch? Die Programmiertools werden (angeblich) immer besser und einfacher, dennoch gibt es immer noch Fehler - sind die Entwickler schlechter geworden?

Wie entstehen Bugs?

Um eine Lösung auf diese Antworten zu finden, bedarf es einer näheren Betrachtung wie Bugs eigentlich entstehen. Bugs lassen sich im Wesentlichen in zwei Kategorien zusammenfassen, meint zumindest Wired-Autor Simson Garfinkel. Einerseits "Typografische Bugs" und Denkfehler, andererseits die tiefgehenden konzeptionellen Bugs, die zu Fehlfunktionen führen auch wenn der eigentliche Software-Code mehr oder wenig fehlerfrei ist.

Beispiele

Buffer Overflows erreichten in den 90er Jahren nahezu epidemische Ausmaße in Programmen, die mit C und C++ geschrieben worden waren, da diese Tools die manuelle Festlegung des Speicherbedarfs erforderten. Ein Buffer Overflow kann nun etwa entstehen, wenn ein Programmierer einen Speicherplatz auf neun Zeichen limitiert, das Programm dann aber mehr Daten speichern will. Ein guter Programmierer kann mit etwas mehr Speicher auch etwas mehr Leistung aus einem Computersystem holen, allerdings steigt auch die Gefahr für Abstürze. Buffer Overflows sind deshalb so beunruhigend, da "verspielte" Hacker oder bösartige Cracker Exploits dazu im Internet anbieten und so zahlreiche Attacken provozieren können, meinen Sicherheits-Experten.

"Type-Safe"-Programmiersprachen

Einen Ausweg aus diesem Speicher-Dilemma sollten so genannte "Type-Safe"-Programmiersprachen bringen, dazu zählen unter anderem Java, Python oder Perl. Diese Programmiersprachen nehmen den Programmierern Arbeit ab, indem sie über Features für automatisches Speichermanagement verfügen. So können zu große Datenmengen zwar abgefedert werden, Bugs werden aber auch dadurch nicht verhindert. Für Tom Ball von den Microsoft Research Studios bedeutet Typesafety alleine noch keinen Durchbruch: "Es eliminiert nicht alle Probleme - es eliminiert eine Klasse von Fehlern".

"Zu viel Freiheit"

Bugs in heutigen Programmen sind kein Resultat von zu geringem Austesten der Software, sondern von "zu viel Freiheit, die Programmierern gegeben wird", meint MIT-Professor Daniel Jackson. Mehr der Freiheit kreativ zu sein, kommt auch die Freiheit Fehler zu machen, meint Jackson. Daher meinen der MIT-Professor und mittlerweile auch viele andere Experten, dass weniger Fehler nur durch weniger Freiheiten für die Programmierer entstehen würden.

Ein Fehler im Konzept

Frustrierend für den optimistischen Glauben der "in-Zukunft-leben-wir-in-einer-Bugfreien-Welt"-Verfechter ist die Tatsache, dass viele Fehler auch bei perfekt codierter Software auftreten. Diese konzeptionellen Fehler treten meist dann auf, wenn das Programm eine Annahme trifft und umsetzt, die nicht den geforderten Ansprüchen der Realität entspricht.

Das Nummernproblem

Das passende Beispiel von Wired betrifft die US-amerikanischen Social Security Numbers: Wenn man verhindert, dass ein Programm, das die Social Security Numbers abfragt, durch eine zu lange Datei (mehr als neun Stellen) einen Buffer Overflow erlebt, so hätte man einen Fehler bereinigt. Doch es bleibt noch ein anderes Problem. "Die Social Security Number als einzigartiges Identifizierungsmerkmal zu sehen, ist der Bug", so Peter Wayner, ein Consultant und Autor zahlreicher Bücher zum Thema Computersicherheit. "In diesem Fall ist der Fauxpas die Annahme dass zwei Menschen niemals die gleiche Nummer haben können - ein Bug, der es ermöglicht, dass Einträge zu zwei Personen durcheinander kommen können, ist hauptverantwortlich für das moderne Verbrechen des Identitätsdiebstahls".

Fazit

"Daher", so Daniel Jackson, "ist die einzige Erfolg versprechende Möglichkeit in der Schlacht gegen Software-Bugs, die Abkehr von der Annahme man könnte sie verhindern". Je mehr Komplexität ein System aufweist, desto mehr Bugs werden sich finden. Daher lautet die Maxime ganz klar: AnwenderInnen von Computern auf denen kritische Systeme laufen, müssen mit einer eingeschränkten Funktionalität leben lernen. "Wenn man ein kritisches System baut, muss man sich eine Prioritätenliste der Anforderung überlegen", so Jackson.(red)

  • Bild nicht mehr verfügbar
Share if you care.