Software::Security
Stenberg: Die Bedrohung durch Hintertüren
Daniel Stenberg, Autor des weit verwendeten Programms Curl, hat seine Gedanken zur Vermeidung von Hintertüren veröffentlicht. Sie lassen sich auf alle freien Projekte übertragen.
Mirko Lindner
Eine Frage die dem Entwickler von
curl Daniel Stenberg häufig gestellt wird, ist, ob er je bemerkt habe, dass jemand versuchte, eine Hintertür in das Programm einzubringen. Verwandte Fragen waren, ob er je gezwungen wurde, solchen Code anzunehmen und in Curl einzubauen, oder welche Hintertür im Zweifelsfall am wenigsten auffällig wäre. Curl könnte für Kriminelle interessanter sein als viele andere Software, da es sich mit Rechnern im Internet verbindet, um Dateien herunterzuladen, und in Form einer Bibliothek in vielen anderen Programmen verwendet wird.
Stenberg kann die ersten beiden Fragen einfach verneinen. Sicher seien durch externe Beiträge bisweilen Fehler verursacht worden, in einigen Fällen auch Sicherheitslücken, eine Absicht sei dabei aber nicht zu erkennen gewesen. Und wenn er selbst an einer Hintertür beteiligt wäre, würde er es nicht verraten.
Wie sich Benutzer jedoch sicher sein können, dass es tatsächlich keine Hintertür gibt, auch wenn sie den Autoren nicht trauen, beantwortet Stenberg im Anschluss, und diese Antworten lassen sich auf alle freien Projekte verallgemeinern. Projekte, die die Fragen noch nicht zufriedenstellen beantworten können, sollten daher darüber nachdenken, vorbeugend aktiv zu werden.
Die sicherste, wenn auch für viele Nutzer nur theoretische Möglichkeit ist, den Code zu untersuchen oder ihn von jemandem zu beziehen, der den Code untersucht hat und dem man vertraut. Dieses Review muss nur einmal durchgeführt werden, bei späteren Versionen genügt es, sich die Änderungen anzusehen. Solche Reviews und Tests können natürlich auch von Projekten durchgeführt werden, die den Code nutzen wollen.
Die Server, die den Code zum Herunterladen anbieten, könnten kompromittiert sein und manipulierten Code verbreiten. Dagegen schützt eine GPG-Signatur des Codes. Sie wird von jemandem aus dem Projekt mit einem privaten Schlüssel erzeugt und kann von jedermann mit Hilfe des zugehörigen öffentlichen Schlüssels verifiziert werden. Dieser Schutz versagt nur dann, wenn das Projekt gezwungen wird, manipulierten Code zu signieren. Es wäre auch denkbar, dass das Benutzerkonto eines Entwicklers kompromittiert wurde, die Hoffnung ist jedoch, dass dies vom Entwickler selbst oder von anderen rasch bemerkt wird.
Das Herunterladen des Codes oder von Binärpaketen von Download-Seiten ist mit Risiken verbunden, auf die das Projekt keinen Einfluss hat. Weniger Risiken bestehen, wenn dieser Code signiert ist, beispielsweise bei den meisten Linux-Distributionen.
Ein Entwickler könnte auch zusammen mit jeder neuen Version eine Art von Versicherung abgeben, dass keine Hintertür eingepflanzt wurde. Beim Ausbleiben dieser Versicherung sollten alle Benutzer alarmiert sein. Dieses Vorgehen würde eventuell gegen staatliche Organisationen helfen, die Strafen androhen können, wenn man die Hintertür verrät, aber nicht, wenn man sie nur indirekt verrät. Für Stenberg wäre dieses Vorgehen mit zuviel Aufwand verbunden, weshalb er es nicht praktiziert.
Die wahrscheinlichste Art, eine Hintertür in Code einzupflanzen, wäre in Curl, eine schwer erkennbare Sicherheitslücke zu verursachen, die später von entsprechendem Code ausgenutzt werden könnte. Direkte Hintertüren wären nach Meinung von Stenberg einfach zu leicht zu erkennen. Stenberg scheint die in Curl entdeckten Sicherheitslücken recht gründlich darauf zu prüfen, ob sie absichtlich verursacht wurden, und konnte bisher kein Anzeichen dafür entdecken.
){kind=small}
