• PT/BR
  • ENG/US

Vulnerabilidades de IPC no Android

  • 24/01/2024
  • Agostinho Sanches de Araujo, Andre Henrique Cunha de Moraes e Sabrina da Silva Miranda 
  • Blog
  • Alto Contraste
  • +Aumentar fonte
  • -Diminuir fonte

O Android é um sistema operacional presente em inúmeros dispositivos pelo mundo, não se limitando a smartphones e tablets, hoje ele está presente em TVs, geladeiras e até mesmo carros. Isso tudo é possível graças a sua arquitetura sofisticada, capaz de suprir demandas específicas e customizações necessárias para cada tipo de dispositivo e diferentes fabricantes. E apesar de sofisticado, ainda oferece certa facilidade para o desenvolvimento de aplicativos e na implementação de funcionalidade adicionais. 

No entanto, por mais robusto e completo que seja um sistema operacional, não é impossível que ocorram erros de programação, vulnerabilidades de segurança e até mesmo falhas de design que possam ser exploradas por agentes maliciosos. 

Neste blogpost, iremos falar sobre comunicações entre diferentes processos (IPC, em inglês, Inter-Process Communication)[1], apresentando uma das funcionalidades do Android responsáveis por elas, chamada Parceable, entendendo como ele funciona e por que foi criado. Após isso, abordaremos vulnerabilidades de segurança que surgiram nesse contexto, como foram corrigidas e os novos mecanismos introduzidos nas novas versões para tentar evitar novas falhas de segurança. 

 

Comunicação de processos no Android 

Para fornecer compatibilidade e permitir troca de informações entre diferentes processos e aplicações, o Android conta com um sistema de comunicação entre processos (IPC). Esse sistema é baseado na serialização de dados em estruturas chamadas bundles, que são objetos utilizados para enviar dados primitivos (bytes, int, char, entre outros). Esses “pacotes” de bytes são enviados para um outro agente chamado Binder[2], que por sua vez, os envia para a aplicação/processo destino, onde serão deserializados e processados. 

No entanto, em algumas aplicações e casos de usos é preciso enviar dados compostos ou complexos, como informações personalizadas específicas de uma classe, e é nessa situação que o uso do Parcel é recomendado. Nesse cenário, é preciso que a classe personalizada implemente o Parceable e utilize os métodos definidos por ele para empacotar e desempacotar os parcels que serão utilizados. 

Caso a implementação desse protocolo de serialização-envio-deserialização contenha erros, vulnerabilidades de segurança podem ocorrer. Dessa forma, dados enviados para aplicativos e/ou serviços mais críticos do Android podem ser intencionalmente corrompidos, resultando em possíveis vazamento de dados sensíveis ou até mesmo a instalação de aplicativos maliciosos (malwares). 

 

EvilParcel Vulnerability 

Uma vulnerabilidade que demonstra o comportamento malicioso descrito no parágrafo anterior ocorreu na CVE-2017-13315, também conhecida como EvilParcel[3]. Para entender como essa vulnerabilidade acontecia, é preciso falar primeiro sobre a falha que ela abusava: 

Foram encontrados erros de compatibilidade entre a escrita (serialização) e leitura (deserialização) de pacotes nas implementações de várias classes que utilizavam a estrutura Parcel[4] para a comunicação entre processos. 

Como os dados se organizam dentro do Parcel: 

 

 

 

A falha encontrada acontecia quando o processo destino, após receber o parcel serializado, realizava a deserialização de maneira incorreta, justamente por conter erros de implementação em seu código, e acabava lendo mais ou menos bytes de cada dado, causando um desalinhamento nos limites dos blocos de dados e bagunçando toda a estrutura do parcel daquele ponto em diante. Uma vez modificados os limites de cada dado dentro do parcel, é possível gerar dados que antes não existiam ou omitir dados. 

Dados organizados após leitura incorreta: 

 

 

Repare que tanto a leitura quanto a escrita eram realizadas em modo sequencial obrigatoriamente, o que forçava o processo destino a desempacotar o parcel completamente antes de acessar qualquer um dos dados nele contido. 

Mas o que é possível fazer com essa falha? 

Em uma comunicação entre três processos era possível adicionar um dado em uma posição intencionalmente calculada na origem, que se tornaria “oculto” para o processo intermediário e apenas se revelaria no destino. 

Desse modo, um programa malicioso poderia enviar um pedido aparentemente comum para um serviço com altos privilégios, passar na validação desse processo intermediário e executar ações que antes não lhe eram permitidas através do serviço privilegiado. No caso do EvilParcel, esse abuso da validação acontecia principalmente na intenção de instalar outros programas ou vazar dados. 

Esquemático do funcionamento da vulnerabilidade EvilParcel: 

 

 

Nova comunicação no Parcelable 

Os desenvolvedores do Android têm continuamente aprimorado o mecanismo de intercomunicação entre processos a fim de evitar bugs e vulnerabilidades de segurança. 

No Android 13, a nova funcionalidade de LazyBundle[5] adicionou mais robustez para a comunicação entre diferentes processos. Com essa nova funcionalidade, os objetos a serem transmitidos continuam sendo serializados em estruturas primitivas como o parcel, porém, com um suporte a estruturas mais complexas, incluindo classes abstratas e objetos com interface. Assim, mesmo quando a estrutura enviada não é de um tipo primitivo, seu tamanho é escrito no Parcel, evitando problemas de compatibilidade entre o que é lido/escrito.Em meio a tantas melhorias, podemos dizer que a mudança mais significativa aconteceu no processo de leitura do parcel, que deixa de ser sequencial e não mais obriga a deserialização completa de pacote para recuperar um único dado, comportamento que deu origem ao nome LazyBundle e que tornou a comunicação entre processos mais rápida e segura. 

 

LeakValue Vulnerability 

O mecanismo de LazyBundle corrigiu vulnerabilidades conhecidas relacionadas ao Parcel, no entanto, também introduziu a possibilidade de novas vulnerabilidades. Esse foi o caso da vulnerabilidade LeakValue (CVE-2022-20452)[6], divulgada em janeiro de 2023, que permitiu a um atacante executar código arbitrário e conseguir privilégios de superusuário no dispositivo. 

O conceito básico dessa vulnerabilidade é semelhante ao da vulnerabildade “use-after-free”, que se dá pelo uso incorreto da memória dinâmica de um programa. Nessa vulnerabilidade, por problemas na implementação, o ponteiro para uma memória que não está mais sendo utilizada (diz-se que a memória foi “liberada” ou “free”) é mantido. Esse erro de implementação permite que um atacante utilize desse ponteiro para quebrar o funcionamento da aplicação ou até mesmo executar comandos arbitrários no sistema. 

A vulnerabilidade LeakValue acontece por uma falha na reciclagem de objetos do tipo parcel, podendo então ser classificada como uma vulnerabidade “use-after-recycle”. 

Ao reciclar bundles do tipo lazy (construídos utilizando o LazyBundle), é possível enviar dados para system servers[7] do Android. Dentre as diversas ações possíveis que os system servers executam, pode-se iniciar o aplicativo de Configurações do Sistema, que por sua vez, pode executar um programa arbitrário controlado pelo atacante e garantir privilégios de superusuário ao atacante. 

 

Conclusão 

Durante os estudos sobre as vulnerabilidades de IPC no Android, foi evidenciado que atacantes estão sempre buscando novas formas de explorar vulnerabilidades e, muitas vezes, utilizam de conceitos e técnicas existentes, readaptando-as para alvos e tecnologias atuais. 

Portanto, não só é preciso estar atento com a vulnerabilidades conhecidas, é também importante estar atento às novas vulnerabilidades que constantemente são divulgadas por pesquisadores ou pela mídia. Pode-se afirmar que nenhum sistema ou solução é 100% segura, nem mesmo as mais recentes ou as que recebem atualizações de segurança, e que toda solução é um alvo em potencial. 

Por fim, é importante realizar auditorias para checar se sua solução, aplicação ou sistema está protegido o suficiente ou que cumpre com as melhores práticas de segurança do momento. Para isso, basta entrar em contato com o time comercial do SiDi e pedir por uma avaliação de segurança. 

 

Referências 

[1] Introdução a IPC no Android: https://medium.com/@vardaansh1/an-introduction-to-android-interprocess-communication-and-common-pitfalls-ac4dfeddf89b [2] Android Binder: https://developer.android.com/reference/android/os/Binder [3] Vulnerabilidade Evil Parcel: https://habr.com/en/companies/drweb/articles/457610/ 

[4] Apresentação da Black Hat: “Android parcels: the bad, the good and the better” https://i.blackhat.com/EU-22/Wednesday-Briefings/EU-22-Ke-Android-Parcels-Introducing-Android-Safer-Parcel.pdf 

[5] LazyBundle – Google https://android.googlesource.com/platform/frameworks/base/+/9ca6a5e21a1987fd3800a899c1384b22d23b6dee%5E%21/ [6] Vulnerabiliade LeakValue: https://github.com/michalbednarski/LeakValue [7] Android System Server: https://medium.com/@khetanrajesh/android-boot-up-process-system-server-940f210d0194 

#SejaSiDier

Faça parte do nosso universo tecnológico

Trabalhe no sidi