Zwischen „Full Disclosure“ und „Security by Obscurity“

Begriffsdefinition

Der Titel dieses Artikels nennt bereits die beiden extremen Standpunkte, „Full Disclosure“ und „Security by Obscurity“. Wie immer sind weiss und schwarz nicht die einzigen Möglichkeiten, es gibt unzählige Abstufungen dazwischen. Betrachten wird dennoch zunächst die Grenzen des Feldes. Anhänger der „Full Disclosure“, also „vollständige Offenlegung“, vertreten die Meinung, dass jeder Anwender über alle Sicherheitsprobleme unterrichtet sein sollte. Dieser Gruppe entgegen stellen sich die Vertreter der „Security by Obscurity“, die „Sicherheit durch Geheimhaltung“ zu erreichen suchen.

Kein Programm ist fehlerfrei. Wenn das Programm fehlerfrei ist, so enthält der Compiler einen Fehler, der das Programm verändert. Da ich noch kein fehlerfreies Programm gesehen habe, ist die zweite Aussage nur eine schwer zu widerlegende These. Wenn jemand in einen fremden Computer eindringen will, so muss er in der Regel Hindernisse überwinden, die dieses Eindringen verhindern sollen. Um an diesen Hindernissen vorbeizukommen muss der Eindringlich Löcher in der Sicherung des Rechners finden. Also Fehler im System oder in Programmen.

Anders als in den Anfangstagen der Datenfernübertragung tummeln sich heutzutage im Internet unzählige Gruppierungen und Einzelpersonen, die es sich zum Ziel gemacht haben, fremde Rechner anzugreifen und sie für ihre Zwecke zu Nutze zu machen. Antrieb kann die Suche nach Speicherplatz genauso sein, wie der Versuch, die Rechner zum Versenden von Werbemails zu benutzen. Jeder Rechner, der mit dem Internet verbunden ist, wird täglich angegriffen. So wie ein Einbrecher sein Brecheisen am Fensterrahmen ansetzt, so setzt ein Angreifer im Internet seinen Hebel an fehlerhaften Programmstellen an. Wenn er sie kennt. Und wenn der Eigentümer sie nicht schon geschlossen hat.

Offene Karten

Findet jemand eine solche Schwachstelle, so kann er versuchen, die Anwender vor dem Problem zu warnen, indem er den Fehler möglichst genau untersucht und beschreibt. Nutzer des Programms können dann geeignete Gegenmaßnahmen ergreifen, das Programm bis zur Behebung des Problems nicht mehr benutzen oder das Problem durch geeignete Einstellungen unterdrücken. Sobald das Problem öffentlich bekannt ist, kann der Anwender reagieren. Aber auch Angreifer kennen ab diesem Zeitpunkt den Fehler. Und die Erfahrung zeigt, dass viele Anwender nicht auf Sicherheitswarnungen reagieren oder reagieren können. Gefundenes Fressen für die Haie.

Genau hier liegt das Problem des Full Disclosure Ansatzes: Zwar könnten die Anwender reagieren, aber sie tun es in der Regel nicht. Ganz im Gegensatz dazu können die Angreifer nicht nur reagieren, sie tun es auch. Spätestens einige Tage, oft auch nur Stunden, nach der Veröffentlichung einer Warnung werden die Lücken aktiv angegriffen. In gewisser Weise kommt die Veröffentlichung einer Warnung den Angreifern also entgegen. Auf der anderen Seite hat jeder Anwender ab diesem Zeitpunkt zumindest die Möglichkeit, sich zu schützen. Gleichzeitig übt das öffentliche Anprangern des Fehlers natürlich Druck auf den Hersteller der Software aus, diese schnell zu reparieren.

Verschlossene Türen

Gerade dieser Druck führt aber unter Umständen dazu, dass die Fehlerkorrektur nicht mit der gebotenen Umsicht durchgeführt oder schlecht getestet veröffentlicht wird. Daher votieren viele Firmen dafür, Fehler in ihrer Software erst zu veröffentlichen, wenn eine korrigierte Version verfügbar ist. Darüber hinaus argumentieren die Verfechter der Security by Obscurity, dass die Fehler häufig erst mit der Veröffentlichung bekannt wird, ein unbekanntes Schlupfloch dagegen keine Gefahr darstellt.

Zwei Probleme stehen diesen vernünftigen Ansichten gegenüber: Zum einen gibt es keine Garantie, dass das Problem wirklich nur dem Entdecker und dem Hersteller bekannt ist. Zum anderen verlassen sich die Hersteller zu gerne auf die vermeintliche Sicherheit und beheben den Fehler spät oder gar nicht. Während man zwar aufgrund der schnellen Reaktionszeiten auf Angriffe im Internet relativ sicher sagen kann, ob ein Fehler bereits ausgenutzt wird oder nicht, führt die verspätete Veröffentlichung von Fehlerkorrekturen dazu, dass Angriffswellen, die hätten verhindert werden können, durch das Internet schwappen können.

Goldene Mitte

Ich selbst bevorzuge bei Sicherheitsproblemen einen Mittelweg, denn beide Konzepte haben ihre Vor- und ihre Nachteile. Das eine gibt den Angreifern unnötige Hilfe, das andere lässt die Anwender schutz- und ahnungslos im Dunkeln stehen. Meiner Meinung nach ist das beste Vorgehen für Finder von Sicherheitslücken, den Fehler zunächst – solange er nicht von Angreifern eingesetzt wird – geheim zu halten und ihn nur dem Hersteller der Software zu melden. Damit der Fehler aber nicht ignoriert oder unter den Teppich gekehrt wird, sollte darauf hingewiesen werden, dass es sich bei der Fehlermeldung lediglich um eine Vorabinformation handelt, dass man die Meldung nach angemessener Frist (oder wenn die Lücke ausgenutzt wird) veröffentlichen wird.

Ein grosses Problem gibt es dabei allerdings: Manch eine Firma wird versuchen, die Veröffentlichung zu verhindern oder sie stellt die Meldung so dar, dass sie einer Nötigung oder Erpressung gleichkommt. Ich würde die Meldung also vorsichtig formulieren: Es erscheint mir sinnvoll, einen Hersteller schlicht um eine Stellungnahme zum gefunden Problem zu bitten, mit dem Hinweis, dass man den Bericht über die Schwachstelle in vier Wochen veröffentlichen möchte. Natürlich hoffe man darauf, in dem Bericht schreiben zu können, dass der Fehler bei Veröffentlichung bereits behoben ist.

Month of the Apple Bugs (MOAB)

Zum Schluss noch einige Worte über den Monat der Applebugs. Die Aktion findet von meiner Seite wenig Zustimmung. Nicht, weil sie gegen den von mir bevorzugten Computerhersteller gerichtet ist – einige der veröffentlichten Fehler sind zweifellos Apple anzulasten – sondern wegen der Art und Weise, auf die die Fehlerberichte umgesetzt wurden und werden.

Als besonders negatives Beispiel ist mir der Bericht vom 8. Januar aufgefallen. Hier wurde auf einen Fehler in einer Dritthersteller-Software hingewiesen, der es lokal angemeldeten Anwendern erlaubt hat, vollen Zugriff auf den Rechner zu erlangen. Soweit alles in Ordnung, der Hersteller hat den Fehler bestätigt. Meine Kritik richtet sich gegen das Beispiel, das die anonymen Betreiber des MOAB bereitgestellt haben.

Um das Problem nachvollziehbar darzustellen, hätte es genügt, den Fehler auszunutzen und eine Datei mit erweiterten Rechten zu erzeugen. Das Beispiel auf der MOAB-Seite hat aber nicht nur den Fehler ausgenutzt, es hat darüber hinaus auch noch ein Programm nachgeladen, das einen neuen Benutzer mit Admin-Rechten anlegt, die systemeigene Firewall deaktiviert und ausserdem auf eingehende Internetverbindungen wartet – wozu habe ich nicht weiter analysiert.

Anstelle den Fehler lediglich zu beschreiben und zu demonstrieren wurde er in meinen Augen ausgenutzt. Welches Ausmaß die „Demonstration“ hat, wurde auf der MOAB-Seite nicht erwähnt. Inzwischen wurde das nachgeladene Programm entschärft, die neue Version habe ich nicht untersucht. Fehler zu melden kann ich gutheißen, egal ob als Full Disclosure oder nur an den Hersteller. Fehler dabei auszunutzen finde ich verwerflich.