Gegenseitig signierte Zertifikate lassen Android abstürzen

Originalartikel von Wish Wu, Mobile Threat Response Engineer

Die Bedrohungsforscher von Trend Micro haben eine Schwachstelle in Android entdeckt, die die Art und Weise betrifft, wie gegenseitig signierte Zertifikate (cross signed) verarbeitet werden. Keine der aktuellen Android-Versionen kann diese Zertifikate korrekt verarbeiten. Es geht um solche Zertifikate, die sich gegenseitig signieren. Das heißt, Zertifikat A signiert B und B signiert Zertifikat A. Google ist über das Problem informiert woden, doch gibt es noch keinen Fix und auch keinen Zeitplan dafür.

Wird ein speziell zusammengestelltes Zertifikat auf ein Android-Gerät gebracht (sei es über die Installation einer neuen App oder über den Import eines Zertifikats), verhält sich das System in nicht vorhersehbarer Weise. Es kann langsamer werden oder hängenbleiben, bis es zu einem Reboot gezwungen wird.

Beschreibung der Sicherheitslücke

Die Lücke entsteht durch zwei allgemein genutzte Klassen im Android-Framework — JarFile und KeyStore. Jede Android-Funktion, die indirekt oder direkt eine dieser Klassen verwendet, läuft Gefahr, durch sich gegenseitig signierte Zertifikate angegriffen zu werden.

  • Androids allgemein genutzte Klasse JarUtils (./libcore/luni/src/main/java/org/apache/harmony/security/utils/JarUtils.java) Diese können von der JarFile-Klasse verwendet werden, um die Zertifikate und Signatur-Dateien eines jar-Pakets zu überprüfen. Leider kann die JarUtils-Klasse mit diesen gegenseitig signierten Zertifikaten nicht richtig umgehen und gerät in eine Endlosschleife. Das gilt für alle Android-Versionen.
  • Androids Klassen der externen KeyStore-Provider (etwa ./external/bouncycastle/src/main/java/org/bouncycastle/jce/provider/JDKPKCS12KeyStore.java) Diese werden dazu eingesetzt, um die PKCS#12-Datei für den Android KeyStore zu verarbeiten. Enthält die PKCS#12-Datei eine Zertifikatsschleife, so gerät die Verarbeitung in den Codes ebenfalls in eine Endlosschleife.

Proof of Concept

Über zwei Szenarien lässst sich die Lücke zeigen. Einmal wird eine speziell erstellte App wird auf das Gerät installiert und im zweiten Fall eine speziell erstellte Key-Kette importiert.

Über die Manipulation des Signierprozesses mit Hilfe verschiedener Signieranfragen für Zertifikate lässt sich auf einfache Weise ein Paar gegenseitig signierter Zertifikate erstellen. A.cert, dessen Aussteller B.cert ist, und B.cert, dessen Aussteller A.cert ist.

Im ersten Szenario wird eine neue App installiert, die mit einem der obigen Zertifikate signiert ist. Eine neue App namens LoopCertsChain, von A.cert signiert, wird auf ein Android-Gerät installiert. Der Screenshot zeigt ein Gerät mit Android 4.1.2, doch sind alle Versionen bis 4.4 betroffen.


Bild 1. Versuch, eine App zu installieren

Bei genauerem Hinsehen fanden die Experten einen Schlüsselprozess (system_server), der die Systemressourcen solange aufbraucht, bis nichts mehr übrig ist. Dies wiederum stößt einen Geräte-Reboot an.


Bild 2. system_server-Prozess, der die Ressourcen aufbraucht

Im zweiten Szenarion importierten die Forscher auf Android eine bösartige PKCS#12-Datei mit einer Signierschleife für Zertifikate.


Bild 3. Importieren der Signierschleife (Keychain)

Der entsprechende Android-Prozess com.android.certinstaller gerät ebenfalls in eine Endlosschleifer, bis er abgewürgt wird.


Bild 4. com.android.certinstaller-Prozess

Diese Lücke hat derzeit keine direkten Sicherheitsauswirkungen. Es geht um den Ressourcenverbrauch. Doch könnte sich später auch herausstellen, dass es weitere Probleme in diesem Bereich gibt, die direktere Konsequenzen haben, etwa die Möglichkeit, beliebigen Code auszuführen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.