Mehr Sicherheit im App-Store Statische Analyse bei Objective-C

Autor / Redakteur: Mark Hermeling * / Stephan Augsten |

Objective-C ist im Apple-Universum besonders beliebt, doch wie bei allen C-Derivaten leidet auch hier die Sicherheit unter strukturellen Mängeln. Statische Code-Analysen können die Code-Qualität deutlich verbessern und die Time to Market senken.

Anbieter zum Thema

Bei der statischen Code-Analyse helfen Hinweise dabei, Ursachen für Fehler wie den hier angezeigten Buffer Overflow schnell zu finden und zu beseitigen.
Bei der statischen Code-Analyse helfen Hinweise dabei, Ursachen für Fehler wie den hier angezeigten Buffer Overflow schnell zu finden und zu beseitigen.
(Bild: GrammaTech)

Wer Anwendungen für iOS und macOS entwickelt, kommt um die Programmiersprache Objective-C – oft als ObjC abgekürzt – in der Regel nicht herum. Sie ist schon lange der Standard im Apple-Universum und wird auch auf absehbare Zeit wohl nicht von Swift verdrängt werden: Laut der Stack Overflow Developer Survey 2017 arbeiten weltweit 7,3 Prozent der professionellen Entwickler bevorzugt mit ObjC. Damit liegt Objective-C zwar weit hinter C++ oder C#, im Apple-Universum hingegen deutlich vor Swift.

Was Freunde der Plattformen von Apple nicht gerne hören: ObjC hat nicht nur Syntax, Performance und Universalität von C geerbt – sondern auch die strukturellen Schwächen, die Anwendungen angreifbar machen. Die Konzepte von C und seinen prominenten Nachfahren C++ und ObjC stammen aus der Vor-Internet-Ära, als die meisten heutigen Angriffsvektoren schlicht nicht möglich waren.

Heute jedoch sind Speicherzugriffsfehler wie Buffer Overruns oder Null-Pointer-Dereferenzierungen der meistgenutzte Angriffsweg, um Schadcode in ein System einzuschleusen. Und gleichzeitig werden Apps und Anwendungen innerhalb der Unternehmen immer kritischer für funktionierende Geschäftsprozesse.

Auch wenn Apple in den vergangenen Jahren massiv an der Sicherheit des gesamten Ökosystems gearbeitet hat, finden sich nach wie vor in vielen Apps und auch in den Betriebssystemen zahlreiche Fehler. Für das Jahr 2017 wies die CVE-Datenbank über 550 Verwundbarkeiten bei Apples eigenen Produkten aus, gut die Hälfte davon erlaubt das Ausführen von fremdem Code. Und auch die Apps von Drittanbietern sind nicht immun gegen Fehler oder Angriffe.

Xcode Add-on für Clang

Apple hat darauf bereits vor einiger Zeit reagiert und in seiner Entwicklungsumgebung ein Add-On für Clang hinzugefügt, das die statische Analyse erlaubt. Das Tool ist kostenlos und gut in Xcode integriert. Für große, komplexe oder verteilte Projekte jedoch fehlen zahlreiche Merkmale wie etwa interprozedurale oder pfadsensitive Analysen.

Abhilfe schafft hier ein umfassendes Analyse-Tool, das für Software-Entwicklung auf Enterprise-Niveau ausgelegt ist; so man eines findet, denn der Markt für Analyse-Tools für ObjC ist noch recht überschaubar. Der Grund dafür dürfte zum einen der vergleichsweise geringe Marktanteil von ObjC sein, zum anderen die Sprache Objective-C selbst.

Das Problem dabei: Um ObjC-Code genau zu untersuchen, reicht es nicht, sich auf den Teil des Codes zu beschränken, der C/C++ gleicht. Denn ObjC hat mit dem Message-Konzept eine Eigenart, die für die Code-Analyse sehr herausfordernd ist: Funktionen werden in ObjC über Messages aufgerufen, die erst zur Laufzeit gebunden werden.

Eine Message ist dabei eine Methode mit allen dazugehörigen Parametern, die an ein Objekt geschickt und von diesem ausgeführt werden. Die Methode, die dabei angewandt wird, wird vom Laufzeitsystem anhand der im Objekt verfügbaren Methoden ausgewählt. Hier weicht ObjC massiv von C++ ab.

Ein einfaches Beispiel dafür:

#import <Foundation/Foundation.h>@interface Base : NSObject
-(int)getBaseNumber;
@end
@implementation Base
-(int)getBaseNumber {
   return 10;
}
@end
@interface Foo : Base
-(int)getNumber;
@end
@implementation Foo
-(int)getNumber {
   return -10;
}
@end
int main() {
   Foo *foo = [[Foo alloc] init];
   int ten = [foo getBaseNumber];
   int minus_ten = [foo getNumber];
   int dbz = 1 / (ten + minus_ten);
   return 0;
}

Trotz der Komplexität des Codes kann die statische Analyse auch bei Objective-C den Entwickler auf Probleme hinweisen.
Trotz der Komplexität des Codes kann die statische Analyse auch bei Objective-C den Entwickler auf Probleme hinweisen.
(Bild: GrammaTech)

Im Zuge der statischen Code-Analyse wird der Code nicht ausgeführt, sondern als Modell mit allen Daten- und Steuerungsflüssen durchlaufen. Das Analyse-Tool muss bei ObjC also eine Annahme über das Ziel der Message treffen und den Codepfad untersuchen, um mögliche Fehler aufzudecken. Das obige Beispiel etwa würde eine Division durch Null ergeben.

Analyse großer Software-Projekte

Es ist also grundsätzlich nicht trivial, ObjC-Code genau zu analysieren. Was in einfachen App-Projekten noch funktioniert, stößt spätestens bei geschäftskritischen Anwendungen für iOS und macOS an seine Grenzen. Denn hier muss nicht nur ein einzelnes Code-Paket analysiert werden, sondern das Testing sollte idealerweise entlang des Software Development Lifecycle als fortlaufender Prozess implementiert sein, der alle Entwicklungsteams umfasst.

Dabei sollte zudem nicht vergessen werden, dass auch bei Anwendungen für Apple-Plattformen immer mehr Code von Dritten zugeliefert wird. Dieser liegt häufig binär vor, etwa bei Krypto-Tools oder Bibliotheken. Je kritischer Software auf den unterschiedlichsten Geräten für den Unternehmensbetrieb wird, desto mehr muss die Sicherheit der Anwendungen ins Zentrum der Entwicklung rücken.

Das klassische Testing stößt bei der heutigen Komplexität der Software-Projekte an seine Grenzen. Statische Analyse kann hier Abhilfe schaffen. Sie ist bereits in frühen Projektphasen nutzbar und kann so als feste, automatisierbare Sicherheitsinstanz innerhalb der Entwicklung dabei helfen, schneller besseren Code zu produzieren. Der dann nicht in der CVE-Datenbank auftaucht.

* Mark Hermeling ist Senior Director Marketing bei GrammaTech, Inc.

Artikelfiles und Artikellinks

(ID:45078474)