Die Entwicklungssicherheit von Open-Source-Software wird oft aufgrund der allgemeinen Zugänglichkeit des Quellcodes in Frage gestellt. Dahinter steht die Annahme, dass ein potenzieller Cracker durch die Untersuchung des Quellcodes dessen Fehler finden könne, um diese Schwachstellen dann für Angriffe zu nutzen. An dieser Theorie ist zwar durchaus etwas dran, allerdings in ganz anderer Hinsicht als allgemein angenommen wird.
Die Analyse des Quellcodes auf für Angriffe geeignete Schwachstellen ist nämlich eine wahre Sisyphusarbeit. Wenn die Aufdeckung solcher Schwachstellen wirklich von der Verfügbarkeit des Quellcodes abhinge, hätte wohl kaum jemand außerhalb von Microsoft je die Sicherheitslücken im Internet Explorer aufspüren können. Diese Untersuchung des Quellcodes stellt für jede einigermaßen komplexe Anwendung eine so aufwendige Aufgabe dar, dass man im Allgemeinen mit Verfahren wie Reverse Engineering viel schneller auf Schwachstellen stoßen kann. Dabei wird eine Arbeitskopie der Anwendung unter die Lupe genommen, indem man fehlerhafte Eingaben und sonstige nicht vorgesehene Aktionen ausführt und die Stabilität des Programms und seine Reaktionen beobachtet. So erkennt man, wann und inwiefern Abweichungen vom gewünschten Programmverhalten auftreten.
Vielleicht wird es einmal ein Programm geben, mit dem man den Quellcode leichter und schneller als mit Reverse Engineering auf Fehler untersuchen kann. Dann wird man dieses Programm jedoch auch auf ausführbare binäre Maschinencodedateien anwenden können, so dass ohnehin kein Zugang zum Quellcode mehr erforderlich ist. Schließlich benötigt man für eine derartige Analyse keine Informationen darüber wie der Programmierer eine bestimmte Variable oder Methode benennt, sondern man muss vielmehr wissen wie die Algorithmen der untersuchten Software aufgebaut sind. Der Maschinencode ist letztlich in seiner Funktion identisch mit dem Quellcode, bevor dieser durch einen Compiler geschickt wurde. Der einzige Unterschied liegt in dessen Lesbarkeit für die einzelnen Programmierer.
Statistisch gesehen spricht nichts dafür, dass die Open Source-Software anfälliger für Schwachstellen ist. So fand Coverity bei einer Codeanalyse des Linux-Kernel-Codes mit 5,7 Millionen Codezeilen nur 985 Bugs. Im Vergleich dazu ergab eine durch das CyLab der Carnegie Mellon University durchgeführte Studie, dass eine typische kommerzielle Closed Source-Software zwischen 20 und 30 Bugs pro 1000 Codezeilen aufweist. Mit diesem Bug-Anteil käme man bei 5,7 Millionen Codezeilen auf mehr als 114.000 Bugs. Das sind über 114 Mal mehr Bugs als beim Linux-Kernel-Code.
Ein wichtiger Aspekt der Softwaretransparenz bei Open Source-Softwareentwicklungen wird oft als Peer Review bezeichnet, also eine Verifikation der Daten durch andere Experten. Da der Quellcode öffentlich ist und die beteiligten Programmierer an keinerlei Vorgaben gebunden sind, wie dies beispielsweise in einem Unternehmen der Fall wäre, wird durch diesen Prozess eine gegenseitige Überwachung sichergestellt. Damit wird auch das sich hartnäckig haltende Argument entkräftet, dass ein böswilliger Programmierer eine ansonsten einwandfreie Open-Source-Software mit einer „Hintertür“ versehen könnte. Durch das Peer-Review-Verfahren und die oftmals sehr strengen und strikt umgesetzten Qualitätsstandards für die Übernahme von Code in die Codebasis eines Open-Source-Softwareprojekts wird dies unterbunden. Vielmehr wäre darauf hinzuweisen, dass ein der Allgemeinheit offen stehender Quellcode von Open-Source-Software das Aufspüren von Anfälligkeiten für Trojaner ermöglicht, während proprietäre Programme, deren Quellcode nicht öffentlich bekannt ist, sogar absichtlich eingebaute Rootkit-Funktionen enthalten könnten, die erst nach deren Verbreitung und dann auch nur zufällig entdeckt werden können, wie dies Ende 2005 beim Sony-Rootkit der Fall war.
Neueste Kommentare
Noch keine Kommentare zu Die Geheimnisse der Open-Source-Sicherheit
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.