CVE-2024-43093

Falha de escalonamento de privilégio local no ExternalStorageProvider do Android Framework, que permite que um app malicioso já instalado (sem permissões extras) burle o filtro que bloqueia acesso a diretórios privados de outros apps (Android/data, Android/obb, Android/sandbox) via Storage Access Framework. É explorada de forma limitada e direcionada segundo o próprio boletim do Google, e está no catálogo KEV da CISA — mas exige interação do usuário, o que reduz o alcance de exploração em massa.

O componente ExternalStorageProvider.java, parte do módulo Documents UI (Project Mainline), expõe diretórios do armazenamento externo via content provider para apps que usam o Storage Access Framework (SAF). O método responsável por decidir se um caminho deve ser ocultado do picker/SAF (shouldHideDocument, segundo a descrição oficial) comparava o caminho solicitado contra um padrão (pattern match) que bloqueia acesso a Android/data, Android/obb e Android/sandbox — diretórios que guardam dados privados de outros apps mesmo em armazenamento 'compartilhado'.

O problema é que essa comparação de padrão não normalizava corretamente sequências Unicode antes de checar o caminho. Isso é uma classe clássica de bypass de canonicalização de nome/caminho (próxima de CWE-706, uso de referência resolvida incorretamente): uma string de caminho pode conter caracteres Unicode que, após normalização pelo sistema de arquivos ou pela camada de resolução de path, colapsam para o diretório sensível, mas que na hora do check de string não batem com o padrão bloqueado — porque o filtro compara a representação bruta, não a forma canônica.

O commit de correção (bug interno 341680936) descreve exatamente isso: trocou a checagem de 'pattern match' por uma checagem de 'equality' sobre o caminho resolvido/canônico, e reforçou a restrição para cobrir também as subpastas de Android/data, Android/obb e Android/sandbox. Ou seja, a causa raiz não era falta de blocklist, era a forma como a blocklist comparava strings antes de decidir liberar o acesso.

O atacante controla o nome/caminho do documento solicitado através do provider (por exemplo, via uma URI de documento manipulada ou nome de arquivo com codificação Unicode específica). Nenhuma permissão adicional é necessária (PR:L cobre o nível de app comum), mas a exploração depende de interação do usuário — plausivelmente concedendo acesso via SAF picker ou instalando/abrindo o app malicioso que dispara a chamada ao provider.

O vetor é local: um app malicioso instalado no dispositivo (sem privilégios elevados, sem MANAGE_EXTERNAL_STORAGE) monta uma requisição ao ExternalStorageProvider usando um caminho ou nome de documento com uma forma Unicode que passa pelo filtro shouldHideDocument sem ser reconhecida como pertencente a Android/data, Android/obb ou Android/sandbox. O resultado prático é acesso de leitura/escrita a arquivos privados de outros apps armazenados nesses diretórios — dados que o modelo de scoped storage do Android deveria isolar por app.

A exploração exige interação do usuário (UI:R), o que na prática normalmente significa abrir o app malicioso, conceder alguma ação através do SAF (como selecionar um arquivo/pasta num picker) ou qualquer fluxo que force o provider a resolver o caminho manipulado. Não há indicação de que a falha seja explorável remotamente ou sem execução de um app atacante no dispositivo — é uma escalada local dentro do próprio aparelho, tipicamente usada como estágio de uma cadeia maior (roubo de dados de outros apps, ou acesso a arquivos que outro app confia e carrega, abrindo caminho para comprometer esse app).

O boletim de segurança do Android de março de 2025 registra explicitamente 'indications that the following may be under limited, targeted exploitation' citando CVE-2024-43093 junto com CVE-2024-50302. A CISA a incluiu no catálogo KEV em 07/11/2024 com prazo de mitigação em 28/11/2024, confirmando exploração real, embora nem o Google nem a CISA tenham detalhado o ator ou a campanha por trás disso — consistente com uso em ferramentas de vigilância/spyware direcionado, mas isso não está confirmado nas fontes oficiais.

A correção está na árvore AOSP (commit em packages/ExternalStorageProvider/src/.../ExternalStorageProvider.java, bug 341680936) e foi distribuída via nível de patch de segurança do boletim Android referenciado como 2024-11-01 (citado nas notas da CISA), sendo listada novamente no boletim 2025-03-01 cobrindo Android 12, 12L, 13, 14 e 15 — tanto como atualização de Framework (SPL 2025-03-01) quanto como atualização do módulo Documents UI via Google Play system update (Project Mainline). Aplicar o nível de patch de segurança de 2025-03-05 ou posterior corrige o problema; dispositivos que recebem atualizações de sistema do Google Play (Mainline) também podem já ter recebido a correção do módulo Documents UI independentemente da atualização completa de firmware.

Como paliativo, não há flag de configuração pública documentada pelo fornecedor para desativar o comportamento vulnerável sem o patch — a correção altera a lógica interna de comparação de caminho, não é um recurso opcional. Em ambientes que não recebem atualização de segurança (device sem suporte do OEM ou sem Google Play Services habilitado para Mainline updates), o controle compensatório realista é restringir a instalação de apps de fontes não confiáveis e depender do Google Play Protect para bloquear apps que tentem abusar do SAF de forma anômala — mas isso não elimina o risco, apenas reduz a superfície de apps maliciosos chegando ao dispositivo.

Não funciona como mitigação: negar a permissão de armazenamento externo ao app malicioso, já que a falha está no lado do provider do sistema (ExternalStorageProvider) e não depende de o app atacante ter permissão de armazenamento tradicional — o acesso ocorre através do mecanismo do SAF/content provider, que é diferente do modelo de permissões de arquivo clássico.

Não há assinatura de rede a procurar — a falha é puramente local, dentro do content provider do sistema de arquivos do Android. Em análise de apps (estática ou dinâmica), o sinal a procurar é uso de caminhos/URIs de documento com sequências Unicode incomuns (caracteres de combinação, formas não normalizadas, homoglifos) direcionados a padrões como 'Android/data', 'Android/obb' ou 'Android/sandbox' em chamadas ao ContentResolver/DocumentsProvider (content://com.android.externalstorage.documents). Em nível de EDR móvel ou telemetria de MDM, monitorar apps que acessam repetidamente diretórios de dados privados de outros pacotes via SAF é o indicador mais próximo de tentativa de exploração, mas não há um log padrão do Android que marque explicitamente esse bypass — a detecção depende de instrumentação customizada ou análise pós-fato do binário do app suspeito.