Gatekeeper Update für Repackaging

In Gatekeeper Bypass – unter Umständen (30. January 2016, 17:30h) hatte ich u. a. über einen Weg berichtet, Code an Gatekeeper vorbeizuschmuggeln, indem man eine saubere App neu vepackt zum Download anbietet. In macOS 10.12 Sierra wurde das Problem behoben. Außerdem gibt Apple einige Entwickler-Tips, wie man das Problem vermeiden kann.

Anfällige Apps

Das Repackaging Problem betrifft bestimmte Apps, die aus anderen Quellen als dem Mac App Store bezogen werden. Manche Apps laden externen Code nach. Beispiele für externen Code sind

die neben der App im selben Disk-Image oder Zip-Archiv liegen, also im selben Container wie die App.

Diese externen Code-Resourcen sind eventuell nicht signiert und die App kann daher deren Integrität nicht sicherstellen. Diese externen Resourcen des Entwicklers können gegen bösartige Inhalte ausgetauscht werden und dann mit der originalen signierten App wie zuvor in einem gemeinsamen Container verpackt werden. Die signierte App wird dann diese im Container mitverpackte Malware benutzen. Handelt es sich zum Beispiel bei dem geladenen Code um eine dynamische Library in einem Plug-Ins Verzeichnis, dann kann so eine App durch Repackaging (neues Verpacken) leicht kompromittiert werden.

Anfällige Verbreitungswege

Für das Repackaging Problem sind Apps anfällig, die auf diesen Wegen verbreitet werden:

Sichere Verbreitungswege

Lösungen

App-Entwickler können das Repackaging Problem komplett ausschließen, indem sie alle Resourcen in das App-Bundle packen. Das App-Bundle ist für den User das, was er als "die App" im Finder sieht. Das App-Bundle ist jedoch tatsächlich ein Verzeichnis, es wird nur als Einheit vom Finder dargestellt.

Apps, die alle Resourcen innerhalb ihres Bundles tragen, können auf diese Weisen sicher verbreitet werden:

Für Apps, die innerhalb eines Containers mit Resourcen verbreitet werden, und daher nicht über den App Store gehen können, sind nur signierte Disk Images sicher:

Vor dem Release der App unbedingt prüfen, ob alle Signaturen gültig sind: Ihre eigene Signatur und die Signatur evtl. benötiger externer Resourcen und die des Disk Images.

Um Lizensierungs-Informationen mit auszuliefern, kann man ein Extended Attribute auf das Root-Bundle setzen. Für weitere Details dazu bitte Tech Note TN2206 lesen. Eine andere Möglichkeit ist, ein personalisiertes Disk Image zu signieren. Keinesfalls sollte die App nach dem Signieren modifiziert werden, ansonsten wird sie Probleme mit Gatekeeper bekommen. Und auf gar keinen Fall soll man ISO Images verwenden.

Gatekeeper Path Randomization

Die oben beschriebenen Punkte waren Hinweise für App-Entwickler, wie das Repackaging Problem vermieden werden kann. Apple hat außerdem noch die Gatekeeper-Funktion erweitert, um das Repackaging-Problem abzufangen für Apps, die sich nicht an diese Empfehlungen halten.

Die Gatekeeper Path Randomization betrifft nicht:

Die Gatekeeper Path Randomization betrifft jedoch:

Apps, die von der Gatekeeper Path Randomization betroffen sind, werden, wenn sie laufen, an eine zufällige Stelle im Datei-System umgesiedelt. Sie sind daher nicht mehr in der Lage, auf ihre externen Resourcen zuzugreifen, die mit im selben Container ausgeliefert wurden. Dadurch wird auch kein Schad-Code, der evtl. den Platz der externen Resourcen eingenommen hatte, mehr geladen.

Allerdings müssen nun Entwickler solcher gefährdeter Apps die oben genannten Regeln beachten, wenn sie weiterhin externe Resourcen verbreiten und in ihrer App laden wollen. Ich habe schon ein paar Entwickler heulen hören, aber bei denen lag es daran, daß sie irrtümlich glaubten, sie hätten jetzt gar keine Möglichkeit mehr, externe Resourcen mit auszuliefern. Lesen ist besser als zu lamentieren, liebe Kollegen.

Quellen-Angaben

WWDC 2016: What's new in Security

Valid XHTML 1.0!

Besucherzähler


Latest Update: 27. August 2016 at 19:27h (german time)
Link: macmark.de/blog/osx_blog_2016-08-a.php