CVE-2026-65995: falha de autorização AIDL no OsmAnd

O OsmAnd 5.3.3 aprovava automaticamente chamadores desconhecidos em um serviço Android AIDL exportado, expondo localização e operações de arquivo a qualquer app instalado no aparelho. O advisory confirma a correção, mas não informa a primeira versão corrigida nem uma pontuação CVSS.

💡 Explicação em Linguagem Simples (ELI5)

Imagine a recepção de um prédio que deveria conferir uma lista de visitantes, mas inclui cada pessoa nova na lista de aprovados assim que ela chega. O serviço do OsmAnd fazia algo parecido com os apps no mesmo celular: cadastrava chamadores desconhecidos como habilitados e então liberava a interface de integração. A correção precisa exigir aprovação explícita e vinculá-la à identidade Android real do chamador.

Conceitos Centrais e Termos

AIDL: Android Interface Definition Language: mecanismo para um processo Android chamar métodos expostos por outro processo via Binder IPC.
Serviço exportado: Serviço Android ao qual outros apps podem se conectar. Métodos sensíveis precisam de permissão ou de uma verificação de chamador equivalente.
UID do chamador: Identidade do processo do app atribuída pelo sistema operacional. O serviço deve obtê-la pelo Binder, sem confiar em um nome de pacote informado pelo chamador.
CWE-862: Classificação editorial da FlawOpen para a ausência de autorização compartilhada. O GHSL lista CWE-862 entre várias fraquezas; o advisory não publica pontuação CVSS.

Mapeamentos de frameworks

Mapeamento conceitual da FlawOpen para o MITRE CWE; nenhum fornecedor ou registro CVE atribuiu este identificador de fraqueza a esta demonstração de pesquisa. CWE-862

Análise de Causa Raiz

O GitHub Security Lab testou o OsmAnd 5.3.3 e encontrou o OsmandAidlServiceV2 exportado sem permissão Android e OsmandAidlApi.isAppEnabled() criando um ConnectedApp desconhecido com enabled=true. Como getApi() condicionava chamadas AIDL a essa verificação, um app local novo era salvo como autorizado em vez de ser negado até a aprovação do usuário. O GHSL relata que isso expunha 97 métodos AIDL, incluindo métodos que retornam dados de localização e navegação e operações de arquivo com falhas de traversal. O atacante precisa ter um app instalado no mesmo aparelho, mas esse app não precisa da permissão de localização nem de outra ação do usuário. Os efeitos em arquivos descritos pelo GHSL ficam no sandbox de armazenamento do OsmAnd, não em todo o sistema de arquivos do dispositivo. Os mantenedores confirmaram as correções em 28/06/2026, mas o advisory não identifica a primeira versão corrigida. Não há pontuação CVSS publicada; a FlawOpen atribui severidade Alta editorialmente porque a falha compartilhada expunha localização sensível e operações que afetam a integridade. CWE-862 é o mapeamento editorial primário da FlawOpen, não uma classificação exclusiva atribuída pelo GHSL.

Fluxo de Ataque Passo a Paso

Passo 1

Um app local alcança o serviço exportado

O serviço vulnerável era exportado sem permissão Android. Um app instalado no mesmo aparelho podia se conectar sem solicitar a permissão de localização do OsmAnd.

Passo 2

A verificação cria a própria aprovação

Para um pacote desconhecido, isAppEnabled() criava e persistia um ConnectedApp com enabled=true. A verificação concedia o acesso que deveria conferir.

Passo 3

A barreira compartilhada libera várias funções

getApi() usava esse resultado para atender chamadas AIDL. O GHSL informa que o caminho alcançava 97 métodos, incluindo getAppInfo() e operações de cópia de arquivos.

Passo 4

O impacto mantém os limites documentados

O app malicioso precisa já estar instalado no aparelho. O GHSL descreve exposição de localização/navegação e efeitos em arquivos dentro do sandbox do OsmAnd; não demonstra acesso ao dispositivo inteiro nem exploração real contra clientes.

Código-Fonte: Vulnerável vs. Seguro

O trecho vulnerável foi citado da análise do GHSL sobre a versão 5.3.3 testada. O exemplo abaixo é um esboço mínimo de política fail-closed, não o patch do OsmAnd nem uma implementação completa: o fluxo de aprovação deve verificar UID, assinatura do pacote instalado, consentimento do usuário e os escopos necessários para cada método. Um serviço de produção deve aplicar autorização na fronteira Binder e restringir cada método sensível. O GHSL confirma a correção, mas não publica o diff completo nem a primeira versão corrigida; atualize para uma versão suportada e confira as orientações atuais do fornecedor. O código é educativo e não inclui exploit ou payload de localização/arquivo.

Trecho de origem: Método: isAppEnabled()

IMPLEMENTAÇÃO VULNERÁVEL

public boolean isAppEnabled(@NonNull String pack) {
    ConnectedApp connectedApp = connectedApps.get(pack);
    if (connectedApp == null) {
        connectedApp = new ConnectedApp(app, pack, true);
        connectedApps.put(pack, connectedApp);
        saveConnectedApps();
    }
    return connectedApp.isEnabled();
}

PATCH SEGURO E ROBUSTO

private final Set<Integer> approvedCallerUids = new HashSet<>();

private boolean isAppEnabled() {
    // Preencha somente após aprovação explícita do usuário e verificação de identidade.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Lista de Verificação de Segurança para Engenharia

✓Atualize o OsmAnd para uma versão suportada. O GHSL confirma a correção, mas não informa a primeira versão corrigida; não deduza o limite de atualização pela data do advisory.
✓Em serviços Android, negue por padrão UIDs Binder desconhecidos. Conceda acesso somente após consentimento explícito e verificação da assinatura do pacote instalado.
✓Aplique autorização na fronteira do serviço exportado e limite cada método AIDL; uma autorização geral não deve liberar automaticamente localização, logs ou operações de arquivo.
✓Trate nomes de pacote recebidos como argumentos como entrada não confiável. Obtenha a identidade por Binder.getCallingUid() e valide os vínculos pacote-UID e certificado de assinatura.
✓Limite operações de arquivo a uma raiz canônica pertencente ao app e rejeite caminhos que escapem dela; autorização não substitui validação de caminho.
✓Revise manifests Android em busca de serviços exportados sem permissão e teste primeiro acesso, revogação, reinstalação/mudança de assinatura e cada método AIDL sensível.
✓O advisory relata um PoC de pesquisa, não exploração confirmada contra aparelhos de clientes. Investigue sinais locais sem tratar a divulgação, por si só, como prova de comprometimento.