Neueste Android-Sicherheitslücke versetzt MediaServer weiteren Schlag

Originalbeitrag von: Wish Wu (Mobile Threat Response Engineer)

Androids mediaserver-Komponente steht weiter unter Beschuss. Wir haben erneut eine Android-mediaserver-Sicherheitslücke entdeckt. Diese lässt sich für Angriffe mit Fremdcode ausnutzen. Ein Angreifer wäre dadurch in der Lage, eigenen Code mit denselben Berechtigungen auszuführen, die das MediaServer-Programm als Teil seiner normalen Routinen verwendet.

Diese Sicherheitslücke wird unter der Bezeichnung CVE-2015-3842 geführt. Sie betrifft die Android-Versionen 2.3 bis 5.1.1. Google hat die Sicherheitslücke über das Android Open Source Project (AOSP) geschlossen und Details darüber veröffentlicht. Aktuell liegen keine Erkenntnisse über laufende Angriffe gegen diese Sicherheitslücke vor.

Diese Entdeckung folgt der kürzlichen Offenlegung drei weiterer ernster Sicherheitslücken in Androids mediaserver-Komponente. CVE-2015-3823 ermöglicht es Angreifern, Smartphones in endlosen Bootschleifen festzusetzen, mittels ANDROID-21296336 lassen sich Geräte stumm schalten und über CVE-2015-3824 (Stagefright) lässt sich Malware mittels Multimedia-Nachrichten installieren.

Wie sich die Lücke ausnutzen lässt

Die Sicherheitslücke involviert AudioEffect, eine Komponente des mediaserver-Programms. Sie prüft eine Variable, die von einem Client – in der Regel eine App – kommt. Die Attacke beginnt damit, dass Angreifer das jeweilige Opfer zu überzeugen versuchen, eine App zu installieren, die keinerlei Berechtigungen einfordert, und gerade dadurch ein falsches Sicherheitsgefühl erzeugen.

Abbildung1

Abbildung 1. Die Android-Oberfläche zeigt an, dass unsere PoC-App keine Berechtigungen einfordert

Die Prüfung der Puffergrößen von pReplyData und pCmdData ist nicht korrekt. Die Puffergrößen sowohl von pReplyData als auch pCmdData sowie der Puffer pCmdData selbst stammen alle von Parametern, die vom Client geliefert werden. Da die mediaserver-Komponente diese Puffer verwendet, liest sie eine Größe, die vom Puffer pCmdData kommt, aus. Dabei nimmt die mediaserver-Komponente an, die Puffergrößen von pReplyData und pCmdData seien größer als diese Angabe. Wir können jedoch die Puffergröße von pReplyData, die vom Client geliefert wird, kleiner machen als den vom Puffer pCmdData ausgelesenen Wert. Dies erzeugt einen Heap Overflow.

Ich habe die entsprechenden Quellcodedateien einer verwundbaren Android-Version (5.1.1) verwendet. Anhand des unten stehenden Screenshots ist der Name der angreifbaren Datei ersichtlich: EffectBundle.cpp.

Abbildung2

Abbildung 2. Heap Overflow-Lokationen

Eine weitere angreifbare Datei ist EffectReverb.cpp.

Abbildung3

Abbildung 3. Heap Overflow-Lokation

Proof-of-Concept

Für den Test habe ich Nexus 6 zusammen mit dem Android 5.1.1 LMY47Z-Image verwendet. Ich habe eine App programmiert, die den Puffer pReplyData zum Überlaufen und damit die mediaserver-Komponente zum Absturz bringt. Unten findet sich ein Ausschnitt des PoC-Quellcodes in Java.

Abbildung4

Abbildung 4. Rufe mNativeAudioEffect von Objekt auf

Unten befindet sich der PoC-Quellcode in C++, der mittels Java aufgerufen wird:

Abbildung5

Abbildung 5. Sende manipulierte Daten an mediaserver

Im PoC kommt es zur Laufzeit der App in der mediaserver-Komponente an einer nicht vorhersagbaren Stelle im Funktionsablauf zum Absturz. Bleibt der Absturz aus, kann die PoC-Datei geschlossen und erneut ausgeführt werden.

Unten befindet sich eines der Crash-Protokolle:

F/libc ( 357): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x7777776b in tid 4757 (Binder_5)
I/DEBUG ( 354): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 354): Build fingerprint: ‚google/shamu/shamu:5.1.1/LMY47Z/1860966:user/release-keys‘
I/DEBUG ( 354): Revision: ‚33696‘
I/DEBUG ( 354): ABI: ‚arm‘ W/NativeCrashListener( 855): Couldn’t find ProcessRecord for pid 357
I/DEBUG ( 354): pid: 357, tid: 4757, name: Binder_5 >>> /system/bin/mediaserver <<<
I/DEBUG ( 354): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7777776b
I/DEBUG ( 354): r0 b3123bb4 r1 b3123bb4 r2 77777777 r3 b404e380
I/DEBUG ( 354): r4 b3123bb4 r5 b589a1c0 r6 b3123bb4 r7 00000003
I/DEBUG ( 354): r8 0000030e r9 b3123bdc sl 00000009 fp b5873b20 I/DEBUG ( 354): ip b6e46d7c sp b3123ba8 lr b6fb1db7 pc b6fb1c26 cpsr 80000030
I/DEBUG ( 354):
I/DEBUG ( 354): backtrace:
I/DEBUG ( 354): #00 pc 0001ec26 /system/lib/libaudioflinger.so
I/DEBUG ( 354): #01 pc 0001edb3 /system/lib/libaudioflinger.so
I/DEBUG ( 354): #02 pc 0002341b /system/lib/libaudioflinger.so
I/DEBUG ( 354): #03 pc 0002045f /system/lib/libaudioflinger.so
I/DEBUG ( 354): #04 pc 00009bef /system/lib/libaudiopolicyservice.so
I/DEBUG ( 354): #05 pc 00016d95 /system/lib/libaudiopolicymanagerdefault.so (android::AudioPolicyManager::getInputForAttr(audio_attributes_t const*, int*, audio_session_t, unsigned int, audio_format_t, unsigned int, audio_input_flags_t, android::AudioPolicyInterface::input_type_t*)+736)
I/DEBUG ( 354): #06 pc 00009701 /system/lib/libaudiopolicyservice.so
I/DEBUG ( 354): #07 pc 00069647 /system/lib/libmedia.so (android::BnAudioPolicyService::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+890)
I/DEBUG ( 354): #08 pc 0001a6cd /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+60)
I/DEBUG ( 354): #09 pc 0001f77b /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+582)
I/DEBUG ( 354): #10 pc 0001f89f /system/lib/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+38)
I/DEBUG ( 354): #11 pc 0001f8e1 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+48)
I/DEBUG ( 354): #12 pc 00023a5b /system/lib/libbinder.so
I/DEBUG ( 354): #13 pc 000104d5 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112)
I/DEBUG ( 354): #14 pc 00010045 /system/lib/libutils.so
I/DEBUG ( 354): #15 pc 00016baf /system/lib/libc.so (__pthread_start(void*)+30)
I/DEBUG ( 354): #16 pc 00014af3 /system/lib/libc.so (__start_thread+6)
I/BootReceiver( 855): Copying /data/tombstones/tombstone_03 to DropBox (SYSTEM_TOMBSTONE)

Mögliche Angriffsszenarien

Dieser Angriff lässt sich lückenlos steuern. Das bedeutet, dass eine bösartige App entscheiden kann, wann ein Angriff beginnen soll und auch wann er enden soll. Ein Angreifer wäre dadurch in der Lage, seinen eigenen Code mit denselben Berechtigungen auszuführen, die mediaserver als Teil seiner normalen Routinen verwendet. Da die mediaserver-Komponente an vielen medienbezogenen Aufgaben wie dem Schießen von Photos, dem Lesen von MP4-Dateien oder dem Aufnehmen von Videos beteiligt ist, ist die Privatsphäre des jeweiligen Opfers in Gefahr. Auch Geräte mit individuell angepassten Android-Versionen, bei denen jedoch die mediaserver-Komponente keine Modifizierung erfahren hat, sind betroffen.

Die Anwender stehen vor dem Problem, dass es schwierig wird, die Ursache eines Angriffs zu ermitteln, sobald er läuft. In unserem PoC haben wir den Angriff einfach dadurch ausgelöst, dass wir eine App ausgeführt haben. Für Demonstrationszwecke ist das üblich und leicht nachvollziehbar. In der Realität jedoch, selbst wenn auch hier Angriffe einfach über Apps gestartet werden können, werden Attacken keine Apps involvieren, die sich mühelos entdecken lassen. Vielmehr wird eine bösartige App alles versuchen, wie eine legitime zu erscheinen, und dynamische Ladetechniken anwenden, um unentdeckt zu bleiben und den eigentlichen Angriff erst mehrere Tage oder sogar Monate später zu initiieren, dauerhaft oder mit Unterbrechungen, ähnlich anderer Malware.

Lösungen

Endanwender können diese Bedrohung schon im Ansatz durch die Installation von Trend Micro Mobile Security (TMMS) abwehren. Diese Lösung ist der Lage, Bedrohungen zu erkennen, die versuchen, diese Sicherheitslücke auszunutzen und eines der präsentierten Szenarien zu verwenden. Android-Anwender können zudem ihr Gerät im abgesicherten Modus neu starten, um die bösartige App zu deinstallieren. Allerdings könnte diese Methode Schwierigkeiten bereiten, speziell für jene Anwender, die nicht so sehr daran gewöhnt sind, an ihrem Gerät neue Dinge auszuprobieren.

Darüber hinaus empfehlen wir, dass die Gerätehersteller regelmäßig Patches zur Verfügung stellen, um ihre Anwender vor Angriffen, die diese Sicherheitslücke ausnutzen, zu bewahren.

Zeitlicher Ablauf der Meldung und Maßnahmen

Wir haben die Sicherheitslücke Google gemeldet. Unten die Details zum Ablauf der Kommunikation und Maßnahmen:

  • 19. Juni: Wir melden das Problem zusammen mit dem entsprechenden PoC an das Android Security Team.
  • 19. Juni: Das Android Security Team akzeptiert die Meldung als Sicherheitslücke hoher Priorität und verleiht ihr die Bezeichnung AndroidID-21953516.
  • 24. Juni: The Android Security Team gibt der Lücke die Bezeichnung CVE-2015-3842.
  • 1. August: Das Android Security Team veröffentlicht das Sicherheitsupdate in AOSP.

 

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.