Objective-C ein Security-Desaster?

[Gast]

Objective-C ein Security-Desaster? Oder ist der Inhalt des untenstehenden Podcasts Unsinn?
Und warum wird nur iOS und kein OSX erwähnt?

Verifying iOS App Behavior
● The current iOS Application model, which uses Objective-C as an option, is FUNDAMENTALLY UNSECURABLE against rogue apps accessing privileged platform functions.
Why?... Because it wasn't originally built to support untrusted applications!! ...And, thus, it cannot do so securely.
● Appleactuallyd epended uponthe“obscurity”ofnotdocumentingrestrictedAPIsinthe file headers.
● Strict process controls, known as “Entitlements” exist, but since the public API libraries also need to use private APIs, the private APIs MUST be accessible within the unprivileged process space.
● “Dynamic code generation” must be provided for Safari’s JIT compiler, but it CAN and IS denied for other apps. But... dynamic code generation is not needed.
● As long as Objective-C, with its dynamic string-based dictionary lookup binding is supported, iOS will be vulnerable.
https://www.grc.com/sn/SN-532-Notes.pdf

https://twit.tv/shows/security-now/episodes/532?autostart=false

[Marscel]

Seriöse Quellen verzichten auf mehrfache Ausrufezeichen und EINDRINGLICH AUFDRINGLICHE WARNUNGEN.

[RattuS]

Die Vorwürfe klingen jetzt nicht unbedingt an den Haaren herbeigezogen, aber wie man am Ausdruck schon erkennen kann, sind sie doch arg dramatisiert. Ich bin kein Objective-C/iOS-Kenner, also zählt meine Meinung aber eh nicht.

[Demirug]

Aus der Sicht der Sicherheit ist die Methode wie bei ObjectiveC Funktionen aufgerufen werden tatsächlich ein Problem. Sobald man ein Objekt hat und den Namen der (internen) Funktion (Selektor genannt) hat kann das System den Aufruf nicht mehr verhindern. Es gibt daher keine klare Schnittstelle zwischen den Applikationen und dem System.

Apple versucht das Problem zu reduzieren indem sie zum einen die Namen der nicht öffentlichen Selektoren versuchen geheim zu halten. Zum anderen werden Apps die in den Store sollen nach der Verwendung von diesen Selektoren durchsucht. Das Problem dabei ist nur das ein Selektor einfach nur ein Text ist. Man kann den Namen also kodiert in der App verstecken und erst zur Laufzeit dekodieren um den Selektor zu erzeugen.

Nun gibt das Problem bezüglich der direkten Ausführung von internen Systemfunktionen unter Umgehung der eigentlichen System-API natürlich auf jedem System. Das Aufruf-model von ObjectiveC macht es im Gegensatz zu anderen Systemen aber sehr einfach die Adresse dieser Funktionen zu finden.

Daran würde sich aber auch nichst ändern wenn Apple jatzt einfach festlegt das alle Programme nur noch mit Swift geschrieben werden dürfen. Denn sobald man mit Swift auf Systemframeworks Zugreift gilt wieder das ObjtiveC Model. Das ist auch bei jeder anderen Sprache (z.B. C# via Xamarin) bei iOS so.

[Ectoplasma]

Denn sobald man mit Swift auf Systemframeworks Zugreift gilt wieder das ObjtiveC Model.

Ja, aber ist man da nicht eher auf C Ebene?

[Demirug]

Ja, aber ist man da nicht eher auf C Ebene?

Der Zugriff auf den Mach Kernel erfolgt in C. Damit hat man aber in der Regel als App Entwickler gar nichts zu tun. Die verschiedenen Frameworks sind fast alle in ObjectiveC geschrieben. Entsprechend muss auch jede andere Programmiersprache hier den ObjectiveC Model beim Aufruf folgen. Selbst bei eigentlich Performances kritischen Schnittstellen wie Metal hat Apple ObjectiveC anstelle von C genutzt. Ich hatte deswegen einiges an Spaß.

[Ectoplasma]

Selbst bei eigentlich Performances kritischen Schnittstellen wie Metal hat Apple ObjectiveC anstelle von C genutzt. Ich hatte deswegen einiges an Spaß.

Hmmm, unter iOS kenne ich mich da nicht so aus. Ich weiss nur, dass das unter OSX defnitiv nicht so extrem ist. Da gibt es noch tonnenweise APIs in C auf User-Level. Z.B. Quartz 2D. Genau genommen braucht man unter OSX nur für die GUI Objective C.