Walled Garden - Ziele und Möglichkeiten
Marc Ruef | 21.10.2013

Modularität ist ein wichtiges Konzept der modernen IT-Landschaft. Viele Produkte bieten mittlerweile das Nachrüsten von Funktionalität mittels Plugins, Addons, Extensions und Apps an. Einer der wichtiger Vorreiter, der dieses Prinzip breitflächig bekannt gemacht hat, ist der populäre Webbrowser Firefox. Mit dem Installieren von Add-Ons wird es gar möglich, den Browser um komplexe Mechanismen wie HTML-Editor, FTP-Client und HTTP-Sniffer zu erweitern.

In anderen Bereichen hat dieses Konzept ebenso Früchte getragen und massgeblich zum Erfolg ganzer Industriezweige beigetragen. Zum Beispiel die beim Apple iPhone nutzbaren Apps, die zusätzliche Software auf dem Gerät installieren lassen. Oder die bei Facebook aktivierbaren Third-Party Applications, durch die Auswertungen, Informations-Austausch und Spiele möglich werden.

Das Problem

Um solche modularen Erweiterungen anbieten zu können, muss die zugrundeliegende Plattform entsprechende Schnittstellen anbieten. Bei Firefox werden auf XML/Javascript zurückgegriffen, bei Apple kommt Xcode/Cocoa zum Einsatz und bei Facebook wird FQL/FBML verwendet. Grundsätzlich erschliessen sich durch ein solches Konzept der Erweiterbarkeit zwei grundlegende Probleme:

1) Ein Angreifer kann die bereitgestellten Schnittstellen angreifen und eine Kompromittierung des Systems anstreben. → Der unerlaubte Zugriff auf geschützte Bereiche (Daten) könnte die Folge davon sein.

2) Ein Angreifer kann die bereitgestellten Mechanismen missbrauchen, um eine böswillige Komponente erstellen und verbreiten zu lassen. → Attacken auf Nutzer und Missbrauch der bereitgestellten Zugriffsmöglichkeiten könnten die Folge davon sein.

Die Angreifbarkeit von Schnittstellen ist für die Nutzer sekundär. Denn in erster Linie ist der Betreiber der Lösung für die Sicherheit dieser verantwortlich. Doch die Verbreitung von korrupten Erweiterungen kann eine direkte Gefahr für die Anwender darstellen. Immerwieder werden Fälle bekannt – bei praktisch allen Anbietern -, bei denen eine Hintertür unentdeckt eingeschmuggelt wurde.

Die Lösung

Apple sieht in ihrem Prozess vor, dass eine für den App Store vorgesehene Anwendung zuerst reviewed werden muss. Erst nach einer Prüfung wird die Freigabe erteilt. Dadurch kann sowohl die Qualität als auch die Sicherheit der App gewährleistet werden. Andere Anbieter, wie zum Beispiel Mozilla oder Facebook, verzichten auf eine solche Review. Die Folge davon ist, dass mit einer relativ hohen Anzahl korrupter Anwendungen in diesen Systemen gerechnet werden muss.

Graham Cluley, ein bekannter Blogger und Mitarbeiter der Firma Sophos, führte nach einer viel diskutierten Weitergabe von Benutzerinformationen einer populären Facebook-Anwendung eine Umfrage durch. In dieser wollte er wissen, wieviele Leute eine Review der für Facebook vorgesehenen Applikationen wünschen:



"Last week, I asked a simple question of our blog readers Should Apple follow Facebook’s example, and have a “walled garden”, verifying all apps? and the response was a resounding “Yes”."



Die Antwort war relativ eindeutig, denn so waren 95.51% der Personen der konservativen Meinung, dass ein solcher Walled Garden von Vorteil wäre. Nur 4.49% vertraten die liberale Meinung, dass auf eine Prüfung und Einschränkung verzichtet werden sollte. (Die Antwort wird voraussichtlich bezüglich anderen Plattformen sehr ähnlich ausfallen.)

Die Möglichkeiten

Das Problem ist, dass eine Prüfung mit sehr viel Aufwand verbunden ist. Jenachdem auf welcher Ebene und wie intensiv die Analyse vorgenommen wird, muss ein Mehr an gut ausgebildetem Personal eingesetzt werden. Eine umfassende Prüfung müsste theoretisch eine Quelltext-Analyse beinhalten. Die Kosten hierfür wären exorbitant hoch und zudem würde sich die Freigabe der Applikationen enorm verzögern. Kein Wunder, ist Apple mit seiner wirtschaftlich guten Stellung bisher das einzige Unternehmen, welches ein Prozess dieser Art durchzusetzen in der Lage ist.

Gerade Facebook beschränkt sich bisher auf eine möglichst restriktive Formulierung der Schnittstellen. Dadurch soll schon von vornherein verhindert werden, dass eine Anwendung mit böswilliger Funktionalität erstellt werden kann. Doch dieser Ansatz ist langfristig zum Scheitern verurteilt, denn es wird immerwieder neue Wege geben, die auferlegten Restriktionen durch kreativen Umgang mit den Möglichkeiten auszuhebeln. Wenn sich zum Beispiel irgendwie geschützte Daten in eine Netzwerkkommunikation einbinden lassen, dann wird das irgendwann auch gemacht werden.

Anbieter wie Facebook täten gut daran, wenn sie neben der restriktiven Implementierung der Schnittstellen ebenso eine möglichst automatisierte Analyse der Anwendungen vornehmen würden. Durch das Identifizieren potentiell gefährlicher Funktionen könnten teilweise automatisiert verdächtige Code-Teile ausgemacht werden. Diese müssten zwar noch immer einem manuellen Review unterzogen werden. Jedoch ist ein erfahrener Analyst oftmals innert weniger Minuten in der Lage zu sagen, ob ein Codeblock nun legitim ist oder nicht.

iDieser Beitrag ist ursprünglich in den scip Labs (http://www.scip.ch/?labs) erschienen./i