Stagefright: a exploração que mudou o Android

Um dos pontos mais fortes do Android tem sido principalmente a sua natureza de código aberto, que permite às partes interessadas bifurcar, modificar e redistribuir o sistema operacional de uma forma que atenda às suas necessidades específicas. Mas essa vantagem de ser de código aberto funciona como uma faca de dois gumes quando se trata de questões de malware e segurança. É mais fácil encontrar e corrigir falhas quando você tem muitos colaboradores competentes em um projeto cujo código-fonte está disponível gratuitamente. No entanto, resolver o problema ao nível da fonte nem sempre se traduz na resolução do problema nas mãos do consumidor final. Como tal, o Android não é a principal escolha quando se trata de escolher um sistema operacional para necessidades empresariais sensíveis a dados.

No Google I/O 2014, o Google deu seu primeiro impulso em direção a um ecossistema mais seguro e favorável às empresas com o lançamento do

Programa Android para Trabalho. O Android For Work adotou uma abordagem de perfil duplo para necessidades empresariais, em que os administradores de TI podiam criar um perfis de usuário distintos para funcionários - um focado no trabalho, deixando outros perfis para uso pessoal dos funcionários usar. Através do uso de criptografia baseada em hardware e políticas gerenciadas pelo administrador, os dados pessoais e de trabalho permaneceram distintos e seguros. Posteriormente, o Android For Work recebeu mais atenção nos últimos meses, com grande foco na segurança do dispositivo contra malware. O Google também planejou ativar a criptografia completa do dispositivo para todos os dispositivos que deveriam ser lançados com o Android Lollipop pronto para uso, mas foi descartado devido a problemas de desempenho com a mudança sendo opcional para implementação pelos OEMs.

A pressão por um Android seguro não é inteiramente trabalho do Google, já que a Samsung desempenhou um papel bastante significativo nisso através de seu Contribuições KNOX para AOSP, que em última análise Android For Work reforçado. No entanto, recentes explorações e vulnerabilidades de segurança no Android apontam para uma tarefa difícil quando se trata de popularidade para adoção empresarial. O caso em questão é a recente vulnerabilidade Stagefright.

Conteúdo:

• O que é Stagefright?
• Quão sério é o Stagefright?
• O que torna o Stagefright diferente de outras “vulnerabilidades massivas”?
• O dilema da atualização
• Android, pós-Stagefright
• Notas finais

O que é Stagefright?

Em termos simples, Stagefright é um exploit que utiliza a biblioteca de códigos para reprodução de mídia no Android chamada libstagefright. O mecanismo libstagefright é usado para executar código que é recebido na forma de vídeo malicioso via MMS, exigindo apenas o número do celular da vítima para realizar um ataque bem-sucedido.

Entramos em contato com nosso especialista interno, desenvolvedor reconhecido sênior XDA e administrador de desenvolvedor pulsador_g2 para fornecer uma explicação mais detalhada.

"Enquanto escrevo isto, o exploit [Stagefright] deveria ser explicado no BlackHat [Link], embora ainda não haja detalhes de slides ou white papers disponíveis.

Portanto, estou dando esta explicação mais como uma ideia aproximada do que está acontecendo, em vez de uma explicação profundamente aprofundada com total precisão, etc.

Existem vários bugs diferentes no Stagefright, e eles têm seu próprio CVE [Vulnerabilidades e exposições comuns] números para rastreamento:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Infelizmente, os patches disponíveis não estão vinculados diretamente a cada CVE (como deveriam ser), então será um pouco complicado explicar isso.

1. [CVE-2015-1538]

No código de manipulação MPEG4, o código de manipulação de metadados 3GPP (aquilo que descreve o formato e outras informações extras, quando um vídeo está no formato 3GPP) apresenta erros. Não rejeitou metadados, onde os dados eram excessivamente grandes, apenas verificando se eram muito pequenos. Isso significava que era possível que um invasor criasse um arquivo “modificado” ou “corrompido”, que teria uma porção de metadados mais longa do que deveria.

Um dos grandes desafios ao escrever código para lidar com dados "não confiáveis" (ou seja, de um usuário ou de qualquer outro tipo de local externo ao seu código) é lidar com dados de comprimento variável. Os vídeos são um exemplo perfeito disso. O software precisa alocar memória dinamicamente, dependendo do que está acontecendo.

Nesse caso, um buffer é criado como um ponteiro para alguma memória, mas o comprimento da matriz para a qual ele aponta era um elemento muito curto. Os metadados foram então lidos neste array, e foi possível fazer com que a última entrada neste array não fosse "nula" (ou zero). É importante que o último item do array seja zero, pois é assim que o software informa que o array terminou. Ao ser capaz de tornar o último valor diferente de zero (já que a matriz era potencialmente um elemento muito pequeno), o código malicioso poderia ser lido por outra parte do código e conter muitos dados. Em vez de parar no final desse valor, ele poderia continuar lendo outros dados que não deveria ler.

(Ref.: OmniROM Gerrit)

2. [CVE-2015-1539]

O menor "tamanho" possível dos metadados deve ser de 6 bytes, por ser uma string UTF-16. O código pega o tamanho do valor inteiro e subtrai 6 dele. Se esse valor fosse menor que 6, a subtração iria "fluir" e se enrolaria, e terminaríamos com um número muito grande. Imagine se você só pudesse contar de 0 a 65535, por exemplo. Se você pegar o número 4 e subtrair 6, não poderá ir abaixo de zero. Então você volta para 65535 e conta a partir daí. É isso que está acontecendo aqui!

Se um comprimento inferior a 6 for recebido, isso poderá levar à decodificação incorreta dos quadros, uma vez que o O processo byteswap utiliza a variável len16, cujo valor é obtido a partir de um cálculo iniciado com (tamanho-6). Isso poderia causar uma operação de troca muito maior do que o pretendido, o que alteraria os valores nos dados do quadro de maneira inesperada.

(Ref.: OmniROM Gerrit)

3. [CVE-2015-3824]

Uma grande coisa! Este é desagradável. Há exatamente o oposto deste último problema - um estouro de número inteiro, onde um número inteiro pode ficar "muito grande". Se você chegar a 65535 (por exemplo) e não conseguir contar mais, você rolará e irá para 0 em seguida!

Se você estiver alocando memória com base nisso (que é o que o Stagefright está fazendo!), você acabará com muito pouca memória alocada no array. Quando os dados eram colocados nisso, eles poderiam substituir dados não relacionados por dados controlados pelo criador do arquivo malicioso.

(Ref.: OmniROM Gerrit)

4. [CVE-2015-3826]

Outro desagradável! Muito semelhante ao último - outro estouro de número inteiro, onde um array (usado como buffer) ficaria muito pequeno. Isso permitiria que a memória não relacionada fosse substituída, o que é novamente ruim. Alguém que pode gravar dados na memória pode corromper outros dados não relacionados e, potencialmente, usar isso para que algum código que eles controlam seja executado pelo seu telefone.

(Ref.: OmniROM Gerrit)

5. [CVE-2015-3827]

Bastante semelhante a estes últimos. Uma variável é usada ao pular alguma memória, e isso pode se tornar negativo durante uma subtração (como acima). Isso resultaria em um comprimento de "salto" muito grande, transbordando um buffer, dando acesso à memória que não deveria ser acessada.

(Ref.: OmniROM Gerrit)

Existem também algumas correções (potencialmente) relacionadas que parecem ter sido incluídas no [Android] 5.1 também.

(Ref.: OmniROM Gerrit)

Isso adiciona verificações para impedir problemas com uma correção de segurança anterior para adicionar verificações de limites, que podem ser ultrapassadas. Em C, os números que podem ser representados como um int assinado são armazenados como um int assinado. Caso contrário, eles permanecem inalterados durante as operações. Nessas verificações, alguns inteiros poderiam ter sido assinados (em vez de não assinados), o que reduziria seu valor máximo posteriormente e permitiria a ocorrência de um overflow.

(Ref.: OmniROM Gerrit)

Mais alguns underflows de inteiros (onde os números são muito baixos e, em seguida, a subtração é realizada nesses números, permitindo que fiquem negativos). Novamente, isso leva a um número grande, em vez de um número pequeno, e causa os mesmos problemas acima.

(Ref.: OmniROM Gerrit)

E finalmente, outro estouro de número inteiro. Como antes, está prestes a ser usado em outro lugar e pode transbordar.

(Ref.: OmniROM Gerrit)"

Quão sério é o Stagefright?

Conforme postagem no blog publicado pela empresa controladora de pesquisa, Zimperium Research Labs, a exploração Stagefright expõe potencialmente 95% dos dispositivos Android - aproximadamente 950 milhões - estão sujeitos a esta vulnerabilidade, pois ela afeta dispositivos que executam o Android 2.2 e acima. Para piorar a situação, os dispositivos anteriores ao Jelly Bean 4.3 correm o “pior risco”, pois não contêm mitigações adequadas contra esta exploração.

Com relação ao dano que o Stagefright poderia causar, pulser_g2 comentou:

[blockquote author="pulser_g2"]"Por si só, o Stagefright daria acesso ao usuário do sistema no telefone. Você teria que ignorar o ASLR (randomização do layout do espaço de endereço) para realmente abusar dele. Se isso foi alcançado ou não, não se sabe neste momento. Essa exploração permite que “código arbitrário” seja executado em seu dispositivo como usuário do sistema ou mídia. Eles têm acesso ao áudio e à câmera do dispositivo, e o usuário do sistema é um ótimo lugar para iniciar uma exploração de root. Lembra de todas as incríveis explorações de root que você usou para fazer root no seu telefone?

Eles poderiam ser usados ​​​​silenciosamente para obter root no seu dispositivo! Quem tem root é dono do telefone. Eles teriam que ignorar o SELinux, mas o TowelRoot conseguiu isso, e o PingPong também. Depois que eles fizerem root, tudo no seu telefone estará aberto para eles. Mensagens, chaves, etc."[/blockquote]Falando sobre os piores cenários, apenas um MMS é necessário para entregar o código e acionar essa exploração. O usuário nem precisa abrir a mensagem já que muitos aplicativos de mensagens pré-processam o MMS antes que o usuário interaja com ele. Isso é diferente dos ataques de spear-phishing, pois o usuário pode ficar completamente alheio a um ataque bem-sucedido, comprometendo todos os dados presentes e futuros do telefone.

O que torna o Stagefright diferente de outras “vulnerabilidades massivas”?

“Todas as vulnerabilidades representam algum risco para os usuários. Este é particularmente arriscado, pois se alguém encontrar uma maneira de atacá-lo remotamente (o que é possível, se uma maneira de contornar o ASLR fosse encontrada), ele poderia ser acionado antes mesmo de você perceber que está sob ataque"

Explorações mais antigas, como Android Installer Hijacking, FakeID, bem como explorações de root, como TowelRoot e PingPong, exigem interação do usuário em algum momento para serem executadas. Embora ainda sejam “explorações”, pois muitos danos podem ocorrer se usados ​​de forma maliciosa, o fato é que o Stagefright teoricamente, precisa apenas do número do celular da vítima para transformar seu telefone em um trojan e, portanto, está recebendo tanta atenção nos últimos dias.

No entanto, o Android não está totalmente à mercê dessa exploração. O engenheiro-chefe de segurança do Android, Adrian Ludwig, abordou algumas preocupações em um Postagem no Google+:

[blockquote author="Adrian Ludwig"]"Existe uma suposição comum e equivocada de que qualquer bug de software pode ser transformado em uma exploração de segurança. Na verdade, a maioria dos bugs não é explorável e há muitas coisas que o Android tem feito para melhorar essas chances...

Uma lista de algumas dessas tecnologias que foram introduzidas desde o Ice Cream Sandwich (Android 4.0) está listada aqui. O mais conhecido deles é chamado Address Space Layout Randomization (ASLR), que foi totalmente concluído no Android 4.1 com suporte para PIE (Position Independent Executables) e agora está em mais de 85% do Android dispositivos. Essa tecnologia torna mais difícil para um invasor adivinhar a localização do código, o que é necessário para que ele crie uma exploração bem-sucedida...

Não paramos com ASLR, também adicionamos NX, FortifySource, Read-Only-Relocations, Stack Canaries e muito mais."[/blockquote]

No entanto, ainda não há como negar que o Stagefright é um assunto sério para o futuro do Android e, como tal, está a ser levado a sério pelas partes interessadas envolvidas. Stagefright também destacou os elefantes brancos na sala – o problema da fragmentação e das atualizações que finalmente chegam ao consumidor.

O dilema da atualização

Falando em atualizações, é bom ver que os OEMs estão assumindo a responsabilidade pela segurança dos usuários, como muitos prometeram fazer. melhorar o processo de atualização especificamente para incorporar correções de segurança e patches para explorações como Stagefright.

Entre os primeiros a divulgar uma declaração oficial, o Google prometeu atualizações mensais de segurança (além das atualizações planejadas de sistema operacional e plataforma) para a maioria de seus dispositivos Nexus, incluindo o Nexus 4 de quase 3 anos. A Samsung também fez o mesmo ao anunciar que trabalhará com operadoras e parceiros para implementar um programa mensal de atualização de segurança mas não especificou os dispositivos e os detalhes do cronograma desta implementação. Isso é interessante porque menciona uma abordagem “rápida” para atualizações de segurança em colaboração com as operadoras, para que possamos espere atualizações mais frequentes (embora baseadas em segurança, mas espero que também acelere as atualizações de firmware) na operadora dispositivos.

Outros OEMs que se juntaram ao grupo incluem LG, que se juntará a atualizações mensais de segurança. A Motorola também anunciou o lista de dispositivos que serão atualizados com correções Stagefright, e a lista inclui quase todos os dispositivos que a empresa fabrica desde 2013. A Sony também disse que seus dispositivos receberão em breve os patches também.

Pela primeira vez, as operadoras também estão trazendo atualizações. Sprint tem emitiu um comunicado que alguns dispositivos já receberam o patch Stagefright, com mais dispositivos programados para a atualização. AT&T também seguiu o exemplo emitindo o patch para alguns dispositivos. A Verizon também emitiu patches, embora este seja um lançamento lento que prioriza smartphones de última geração como o Galaxy S6 Edge e o Note 4. O T-Mobile Note 4 também recebeu uma atualização de patch Stagefright.

Como usuário final, existem algumas medidas de precaução que podem ser tomadas para diminuir suas chances de ser atacado. Para começar, desative a recuperação automática de mensagens MMS nos aplicativos de mensagens presentes no seu telefone. Isto deve manter sob controle os casos em que nenhuma interação do usuário foi necessária para que a exploração funcionasse. Depois disso, tome cuidado para evitar baixar mídia de mensagens MMS de fontes desconhecidas e não confiáveis.

Como um usuário avançado do XDA, você também pode faça edições em seu build prop para desativar o Stagefright. Esta não é uma maneira completa e infalível de se salvar do Stagefright, mas você pode arriscar para diminuir a probabilidade de um ataque bem-sucedido se estiver preso em uma versão mais antiga do Android. Existem também soluções ROM personalizadas, a maioria das quais sincroniza fontes com AOSP regularmente e, portanto, terão as correções Stagefright incorporadas. Se você estiver executando uma ROM baseada em AOSP, é altamente recomendável que você atualize para uma versão mais recente da ROM que incorpore os patches Stagefright. Você pode usar este aplicativo para verificar se o seu driver diário atual é afetado pelo Stagefright.

Android, pós-Stagefright

Stagefright nada mais foi do que um alerta para o Android e seu problema de fragmentação e também de atualizações. Ele destaca como não existe um mecanismo claro por meio do qual essas correções críticas possam ser implementadas em tempo hábil em vários dispositivos. Embora os OEMs estejam tentando lançar patches para dispositivos, a dura verdade é que a maioria dessas correções será limitada apenas aos carros-chefe recentes. Outros dispositivos não emblemáticos e mais antigos, muito menos de OEMs menores, continuarão expostos a dispositivos como o Stagefright.

Há uma fresta de esperança nesta façanha: Ele chamou novamente a atenção sobre o processo de atualização do Android e lançou-o sob uma luz que não atrairá tantas futuras empresas corporativas para a adoção do Android para uso empresarial. À medida que o Google trabalha para uma maior adoção empresarial, será forçado a repensar sua estratégia de atualização e a quantidade de controle que permite aos OEMs.

Com o Android M se aproximando do lançamento no mercado a cada dia, não seria surpresa se o Google decidisse separar cada vez mais componentes do AOSP em favor de seu pacote de serviços Play. Afinal, essa é uma área sobre a qual o Google ainda mantém controle total se um dispositivo for enviado com a Google Play Store. Esse tem suas próprias desvantagens na forma de substituição de áreas de código aberto por paredes de código fechado.

Ao especular sobre o futuro do Android, há uma possibilidade (muito pequena) de que o Google também limite as mudanças que os OEMs podem fazer no AOSP. Com o Estrutura RRO estando presente em estado funcional no Android M, o Google poderia restringir os OEMs a fazer apenas alterações cosméticas na forma de skins RRO. Isso deveria permitir uma implantação de atualização mais rápida, mas custaria aos OEMs a oportunidade de personalizar totalmente o Android.

Outro caminho que pode ser uma possibilidade seria torná-lo obrigatório para todos os dispositivos enviados com Google Play Store receberá atualizações de segurança garantidas por um período fixo, possivelmente dois anos. A estrutura do Play Services poderia ser usada para verificar a presença de atualizações e patches de segurança importantes, sendo o acesso à Play Store rescindido em caso de não conformidade.

Notas finais

Na melhor das hipóteses, isso ainda é especulação, pois não existe uma maneira elegante de resolver esse problema. Na ausência de uma abordagem muito totalitária, haverá sempre algumas lacunas no alcance de soluções. Devido ao grande número de dispositivos Android disponíveis, acompanhar o status de segurança de cada dispositivo seria uma tarefa gigantesca. A necessidade do momento é repensar a forma como o Android atualiza, já que a forma atual certamente não é a melhor. Nós do XDA Developers esperamos que o Android continue fiel às suas raízes de código aberto enquanto trabalha junto com os planos de código fechado do Google.

O seu telefone é vulnerável ao Stagefright? Você acha que seu telefone algum dia receberá um patch Stagefright? Deixe-nos saber nos comentários abaixo!