Die Woche: Trau, schau, wem?

@ctmagazin | Kommentar

Die Diskussion über eine mögliche Backdoor in IPsec zeigt, dass Software durch Veröffentlichung der Quellen nicht automatisch sicherer wird. Anwender müssen nach wie vor darauf vertrauen, dass Programmierer nichts Böses im Schilde führen.

Ausgerechnet in der OpenBSD-Implementation des Sicherheitsprotokolls IPsec, mit dem VPN-Verbindungen aufgebaut werden, soll seit Jahren eine Backdoor des FBI schlummern und sogar den Sprung auf andere BSD-Varianten sowie Linux geschafft haben.

Die Anwender sind geschockt: Wie konnte eine Backdoor all die Jahre unbemerkt bleiben, wo doch die Quellen offen liegen?

Diese Frage muss sich eigentlich jeder stellen, der IPsec einsetzt: Warum hat er die Quellen nicht selbst auf etwaige Sicherheitslücken und Backdoors hin abgeklopft? Weil das natürlich viel zu aufwendig ist und die meisten überhaupt gar nicht über das dafür nötige Fachwissen verfügen. Außerdem hat ja auch kein anderer Entwickler Alarm geschlagen. Es haben also alle darauf vertraut, dass die Entwickler schon nichts Böses im Schilde führen.

Angesichts der Fülle an Software, die wir heute einsetzen, geht es auch nicht anders: Man muss den Herstellern von Programmen vertrauen, dass sie Software nach bestem Wissen und Gewissen schreiben und keinen böswilligen Code einfügen. Bei Closed-Source-Entwicklungen hat man gar keine andere Wahl, weil man die Quellen gar nicht erst zu Gesicht bekommt.

Durch die Herausgabe der Quellen steigt jedoch nicht automatisch die Sicherheit – denn es muss ja erst eine ensprechend fachkundige Person den Quellcode lesen, ihn verstehen und ihn schließlich auf Sicherheitslücken hin untersuchen. Solche Code Audits übernehmen üblicherweise Spezialisten wie die Firma Coverity oder entsprechend versierte Entwickler aus der Open-Source-Gemeinde – und trotzdem ist die Chance gering, dass sie absichtlich eingebauten Schadcode wie zum Beispiel eine Backdoor finden.

Das liegt schlicht daran, dass es fast unendlich viele Möglichkeiten gibt, wie ein Programmierer etwas implementiert – und angesichts der Abermillionen Zeilen Code heutiger Programme gibt es auch genügend Verstecke.

Im einfachsten Fall fehlt absichtlich eine Bereichsprüfung, die einen Pufferüberlauf verursacht und so Angriffmöglichkeiten schafft – und im schlimmsten Fall steckt der Fehler gar nicht im Code, sondern im zugrundeliegenden Algorithmus. Und ein algorithmischer Fehler lässt sich weder mit Review-Tools noch durch Betrachten des Codes finden.

Wie gut sich Schadcode verstecken lässt, zeigt der Underhanded C Contest aus 2008 sehr anschaulich: Dort galt es, eine Bilddatei zu manipulieren, ohne dass dies auch bei genauer Betrachtung des Quellcodes zu entdecken ist. Der Code des Gewinners, Mr. Meacham, war so gut, dass nicht einmal die Veranstalter des Wettbewerbs schlüssig beschreiben konnten, wie er arbeitet – der Entwickler musste die Erklärung später selbst in seinem Blog liefern.

Es ist also schlicht unmöglich, mit Sicherheit zu verhindern, dass ein Programmierer absichtlich Schadcode einfügt. Dementsprechend werden die meisten Backdoors in Programmen, egal ob Open oder Closed Souce, nur durch Zufall gefunden oder weil sie jemand ausgenutzt und dabei Spuren hinterlassen hat.

Somit bleibt den Anwendern nur, sich die Firmen oder Entwickler anzusehen, deren Software sie einsetzen wollen – und zu entscheiden, ob sie ihnen vertrauen oder nicht. (mid)

Forum zum Thema

Kommentare

Kommentare lesen (33 Beiträge)

Infos zum Artikel

33Kommentare
Kommentare lesen (33 Beiträge)
  1. Avatar
  2. Avatar
  3. Avatar
Anzeige

Anzeige

Anzeige