Was passiert ist: Charlie Miller, ein bekannter Entwickler und Security-Experte der iOS-Plattform hat (nicht zum ersten Mal) ein Sicherheitsproblem entdeckt. Diesmal konnte er nicht weniger als beliebigen, nicht-signierten Code in einer Anwendung des Appstores zur Ausführung bringen, wie er in einem Video demonstriert. Daraufhin hat Apple nicht nur seine Testanwendung aus dem Appstore entfernt, sondern ihm auch seinen Developer Key entzogen - damit ist es ihm nicht mehr möglich, Anwendungen für das iPad oder iPhone zu entwickeln.
Hintergrund
Apples Security-Konzept basiert auf Codesigning und einem Reviewprozess. Eine Anwendung, die in den Appstore soll (die einzige Quelle für Software im iOS-Universum), wird zunächst von Apple in einem Reviewprozeß untersucht. Die Details dieses Reviewprozesses sind unbekannt, es wird dabei jedoch auf Designkriterien (muß dem Styleguide entsprechen), Inhalt (Jugendschutz, nackte Haut, volksverhetzende Aussagen, etc.) und Sicherheit (böswillige, versteckte "Zusatzfunktionen") geachtet. Hierzu wird jedoch nicht der Sourcecode, sondern nur das fertige Binärpaket herangezogen. Ist der Test zur Zufriedenheit von Apple, erhält die Anwendung eine digitale Signatur und wird in den Appstore gestellt.
iPhone und iPad prüfen bei dem Versuch, eine Anwendung zu installieren, deren Signatur. Nur mit einer gültigen Signatur wird die Anwendung installiert - alles andere muß draußen bleiben. Da aber Entwickler ihre Anwendungen testen müssen, erhalten sie (gegen eine jährliche Gebühr) einen speziellen Entwicklerschlüssel, der es ihnen erlaubt, auf ihren eigenen Geräten (und nur diesen) Anwendungen zu installieren.
Fail 1: "Professioneller" Umgang mit Sicherheitslücken
Charlie Miller hat nun - wieder einmal - ein Problem entdeckt und dies öffentlich gemacht. Leute mit ausreichend krimineller Energie hätten solche Schwächen für sich behalten, selbst ausgenutzt oder verkauft (es gibt für Zero-Day Exploits inzwischen wohl einen durchaus lukrativen Markt). Er entschied sich aber, die Öffentlichkeit zu informieren und so Apple die Möglichkeit zu geben, das Problem zu beheben.
Eigentlich sollte Apple solchen Leuten dankbar sein - stattdessen aber wirft Apple ihn aus dem Entwicklerprogramm (was dank des restriktiven Einsatzes DRM-Technologien möglich ist). So geht man nicht mit solchen Leuten um!
Fail 2: Der Review-Ansatz
Apples Security-Konzept fußt darauf, daß während des Reviews böswillige Programme erkannt werden. Nach der Installation gibt es (im Gegensatz zu Androids Privileges) keine weiteren Maßnahmen, welche den Schaden in irgendeiner Weise einschränken; so hat beispielsweise jede Anwendung Zugriff auf das Internet - egal, ob sie es für ihren (offiziellen) Zweck bräuchte oder nicht. Eine sehr ähnliche Debatte erlebten wir gerade beim Staatstrojaner: Auch hier ging es darum zu beweisen, daß das Programm eine bestimmte Funktionalität nicht hat. Aus Sicht der theoretischen Informatik ist das nicht möglich - das besagt das Halteproblem. Aber auch in der Praxis kann man Funktionalität beliebig kompliziert verschleiern, so daß die Reviewer bei Apple (welche ja tausende Einreichungen pro Tag reviewen müssen) hier kaum eine realistische Chance haben dürften. Offenbar gelang es Charlie Miller, solche Zusatzfunktionen am Reviewprozeß von Apple vorbeizuschmuggeln - und demonstrierte so die Unsicherheit und Unvollständigkeit des Prozesses, und rüttelte damit quasi an den Grundfesten des iOS-Security-Konzeptes.
Fail 2b: Die Artikelüberschrift bei t3n
Der Bericht bei t3n hierzu ist betitelt mit Fehler in Apples Codesigning reduziert Sicherheit auf Android-Niveau. Das ist - wie man aus der vorigen Beschreibung sehen kann - schlicht falsch. Der Fehler reduzierte die Sicherheit unter Android-Niveau... genauer Gesagt in Richtung null. Eine Anwendung unter Android kann (egal, ob böswillig oder offiziell) nur die Funktionen nutzen, welche der Benutzer bei der Installation abgenickt hat. Dafür sorgt das Konzept der Privilegien. Natürlich setzt das eine gewisse Aufmerksamkeit des Users voraus ("Wieso braucht ein Tetris-Clone Zugriff auf meine aktuelle Position und das Internet? Nein, das installiere ich lieber nicht"), und auch an der Granularität der Privilegien gibt es berechtigte Kritik... aber das ist immer noch deutlich besser als der Schutz unter iOS.
Edit: Mehr Details...
Dieser Artikel bei Heise erläutert ein paar technische Details mehr. Ich hatte zunächst vermutet, daß Miller einen Fehler in der Review-Methodik (und damit eine Möglichkeit, Code am Reviewprozeß "vorbeizuschmuggeln") ausfindig gemacht hat; dem Artikel nach liegt das Problem aber in der neuen JavaScript-Engine Nitro; nach einer JIT-Kompilierung von Javascripts hat das Kompilat wohl alle Kompetenzen einer (signierten) Anwendung. Normalerweise sollte nur der Browser Zugriff auf Nitro haben - irgendwo hier dürfte die von Miller entdeckte Lücke stecken.