Novos golpes estão atingindo o componente do mediaserver do Android. Descobrimos mais uma vulnerabilidade no mediaserver do Android, que pode ser explorada para realizar ataques envolvendo execução de código arbitrário. Com essa nova vulnerabilidade, um agressor pode executar seu código com as mesmas permissões que o programa mediaserver já tem como parte de suas rotinas normais.
Essa vulnerabilidade foi designada como CVE-2015-3842. Apesar de afetar as versões 2.3 até a 5.1.1 do Android, o Google corrigiu e publicou detalhes dessa vulnerabilidade através do Projeto Código Aberto do Android (AOSP). Atualmente, não há ataques ativos conhecidos contra essa vulnerabilidade.
Essa descoberta segue de perto três outras grandes vulnerabilidades nos componentes do mediaserver do Android que apareceram recentemente. A CVE-2015-3823 pode permitir que agressores aprisionem telefones em reinicializações sem fim, a ANDROID-21296336 pode silenciar os dispositivos e a CVE-2015-3824 (Stagefright) pode ser usada para instalar malware através de uma mensagem multimídia.
Como funciona
A vulnerabilidade envolve o AudioEffect, um componente do programa mediaserver. Ela usa uma variável não verificada que vem do cliente, normalmente um aplicativo. Para um ataque começar, os agressores convencem a vítima a instalar um aplicativo que não requer nenhuma permissão, dando uma falsa sensação de segurança.
Figura 1. Interface de Usuário do Andoid mostrando a falta de permissões exigidas por nosso aplicativo POC (prova de conceito).
A verificação dos tamanhos do buffer do pReplyData e do pCmdData não é correta. Os tamanhos do buffer do pReplyData, do pCmdData e do próprio buffer do pCmdData vêm todos com parâmetros fornecidos pelo cliente. Como o componente do mediaserver usa esses buffers, ele lê um tamanho vindo do buffer pCmdData; o componente do mediaserver supõe que os tamanhos do buffer do pReplyData e pCmdData são maiores que esse tamanho. Podemos fazer o tamanho do buffer do pReplyData, que é fornecido pelo cliente, menor do que o tamanho lido a partir do pCmdData do buffer. Isso causa um “heap overflow”.
Eu usei os arquivos do código fonte relacionado a partir de uma versão vulnerável do Android (5.1.1). Na captura de tela abaixo, podemos ver que o nome do arquivo vulnerável é EffectBundle.cpp.
Figura 2. Locais do Heap Overflow
Outro arquivo vulnerável é o EffectReverb.cpp.
Figura 3. Locais do Heap Overflow
Demonstração de Prova de Conceito
Decidi testá-lo usando um Nexus 6 com a imagem LMY47Z do Android 5.1.1. Escrevi um aplicativo que quebra o componente do mediaserver fazendo um “overflow” do pReplyData do buffer no heap. Abaixo está uma parte do código fonte da linguagem Java do PoC.
Figura 4. Get mNativeAudioEffect do objeto
Abaixo está o código fonte da linguagem C++ do PoC, que é invocado pelo Java:
Figura 5. Enviar dados malformados para o mediaserver
No PoC, quando o aplicativo está sendo executado, o componente do mediaserver falhará como uma função aleatória. Se o componente do mediaserver não falhar, o aplicativo PoC pode ser fechado e executado novamente.
Abaixo está um dos registros de relatórios de falha:
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)
Possíveis cenários de ameaças
Esse ataque pode ser totalmente controlado, o que significa que um aplicativo malicioso pode decidir quando começar o ataque e também quando parar. Um agressor pode executar seu código com as mesmas permissões que o programa mediaserver já tem como parte de suas rotinas normais. Como o componente do mediaserver lida com um monte de tarefas relacionadas a mídia, inclusive tirar fotos, ler arquivos MP4 e gravar vídeos, a privacidade da vítima pode estar em risco. Dispositivos com versões personalizadas do Android, mas sem modificações feitas para o componente do mediaserver, também foram afetados.
O dilema que os usuários podem enfrentar é a dificuldade de localizar a causa quando um ataque acontece. Em nossa demonstração, simplesmente acionamos o ataque executando um aplicativo. É conveniente e intuitivo para divulgação. Embora os ataques possam ser acionados apenas pelo aplicativo, os ataques no mundo real não envolverão aplicativos fáceis de serem detectados. O aplicativo malicioso tentará, o máximo possível, parecer legítimo usando uma tecnologia de carga dinâmica que permanece indetectada enquanto dispara o ataque vários dias/semanas mais tarde, ou de maneira persistente ou intermitente, do mesmo modo que outros malwares.
Soluções
Usuários domésticos podem bloquear essa ameaças desde o início baixando o Trend Micro Mobile Security (TMMS), que pode detectar ameaças tentando usar essa vulnerabilidade e executar qualquer um dos cenários apresentados. Os usuários do Android também podem reiniciar seus dispositivos usando o modo seguro para desinstalar o aplicativo malicioso. Porém, esse método pode se mostrar difícil, especialmente para as pessoas não acostumadas a mexer com seus dispositivos.
Cronograma de Divulgação
Essa vulnerabilidade foi divulgada para o Google, com os detalhes descritos abaixo:
19 de junho: Informamos o problema, juntamente com o PoC correspondente, para a Equipe de Segurança do Android.
19 de junho: A Equipe de Segurança do Android aceitou que era uma vulnerabilidade de alta gravidade e designou o AndroidID-21953516 para ela.
24 de junho: A Equipe de Segurança do Android designou a CVE-2015-3842 para ela.
1º de agosto: A Equipe de Segurança do Android publicou a correção no AOSP.
Publicado originalmente por Wish Wu (Mobile Threat Response Engineer) em TrendLabs.
