Pesquisador demonstra duas falhas de OxygenOS no OnePlus 15 que permitem root com app local

Um pesquisador em segurança, Rasmus Moorats, demonstrou que um OnePlus 15 com a última versão de OxygenOS pode ser tomado por completo por uma aplicação maliciosa que o proprietário instala voluntariamente, mesmo que essa app não solicite permissões especiais. Moorats encadenou duas falhas em software próprio da OnePlus para escalar privilégios até atingir root - o nível mais alto de controle em um telefone Android - e publicou seus achados em 24 de setembro após vários meses de comunicação com a empresa. OnePlus confirmou em maio a existência das duas vulnerabilidades e declarou que problemas similares afetam mais modelos seus e outros de OPPO, embora não identificou quais.

Em termos técnicos, a cadeia de exploração utiliza dois serviços pré-instalados de OxygenOS. O primeiro é AtlasService, um serviço que coleta dados de depuração e que, segundo Moorats, corre com privilégios de root e aceita chamadas de qualquer aplicativo sem verificar a identidade de quem chama. Uma petição especialmente construída alcança uma ferramenta de depuração que toma texto fornecido pela aplicação e o insere sem saneamento em um comando do sistema. Esse erro por si só concede privilégios root dentro de uma zona do sistema chamada dumpstate; é um root funcional mas restrito. O segundo erro é independente e complementar: um serviço de hardware chamado olc2 que oferece uma interface para executar comandos de shell. Sua única barreira é verificar que o chamador já tenha privilégios root. Com a primeira vulnerabilidade obtém-se esse root em dumpstate, e com a segunda é executado um comando num contexto que concede privilégios Linux de baixo nível, incluindo a possibilidade de carregar código no kernel. O resultado final é controle a nível do sistema sobre o dispositivo.

É importante ressaltar que o ataque é local: Você precisa que o aplicativo maliciosa tenha sido instalado e esteja sendo executado no telefone; você não pode se lançar remotamente através da Internet sem interação local. No entanto, as condições necessárias para iniciar a exploração são mínimas: segundo o pesquisador, não pede permissões especiais nem mostra nenhum aviso ao usuário, e funcionou em um telefone de série sem modificações.

Os fatos confirmados na cronologia que proporcionou Moorats são claros: a notificação inicial à OnePlus foi em 18 de abril; a empresa confirmou as falhas em 20 de maio e, nessa comunicação, afirmou que controlaria a divulgação e que a publicação sem seu consentimento poderia acarretar responsabilidade legal. OnePlus informou que programaria uma correção, pediu a Moorats para aguentar e deu-lhe uma data até que não publicar; quando essa data chegou e não houve arranjo público, Moorats publicou em 24 de setembro. No momento de sua divulgação não existia um CVE atribuído nem um adesivo disponível, segundo sua relato. Moorats também reproduziu a cadeia em um OnePlus 12 Pro e estima que o problema afeta de forma geral OxygenOS 16; OnePlus e OPPO compartilham uma base de software que explicaria a cobertura entre marcas.

O que se sabe com certeza e o que não: É confirmado que Moorats encontrou e combinou duas falhas em serviços de OxygenOS que permitem escalar o root quando uma app maliciosa está instalada. Também está confirmado que OnePlus foi informado, reconheceu as falhas em maio e advertiu sobre a divulgação. É confirmado que, segundo Moorats, não há evidência pública de exploração no mundo real até a data de sua publicação. No que concerne a alcance exato de dispositivos afetados e datas de adesivo, isso ainda é incerto: OnePlus não publicou uma lista de modelos nem um aviso técnico público nem deu um calendário de correção verificável ao momento da divulgação.

As consequências práticas para usuários e administradores são claras no modelo de ameaça desta falha: um atacante só precisa convencer ou enganar o proprietário para instalar uma aplicação localmente - por exemplo, mediante sideloading, um pacote adjunto ou um link para instalar fora de lojas oficiais - e essa aplicação pode ser aumentada silenciosamente para root sem pedir permissões. Com o root e a capacidade de carregar o código do kernel, um atacante pode instalar a persistência profunda, desactivar os controlos de segurança, aceder a dados criptografados em memória e esconder a sua presença. Em ambientes corporativos isso equivale a perder o controle do dispositivo e potencialmente do acesso a sistemas da empresa se o telefone for usado para autenticação ou correio.

A dificuldade real de explorar este vetor está no primeiro passo: a instalação da app maliciosa. Até os fornecedores publicarem e implantarem adesivos, a defesa mais prática e efetiva para usuários finais é restringir a instalação de aplicativos a fontes de confiança. Evitar sideloading, não instalar APKs provenientes de terceiros e usar lojas oficiais com proteções (como o Google Play com Play Protect) reduz significativamente o risco. A cadeia descrita por Moorats não prospera sem um aplicativo local instalado.

Recomendações concretas e comprováveis para usuários:

1) Não instalar aplicativos fora de lojas oficiais e, se necessário, verificar a origem e a assinatura do APK. Desactiva a instalação de “orígenes desconhecidos” nos ajustes do sistema quando não for necessário. 2) Mantenha a depuração USB desactivada, a menos que seja usada ativamente e supervise os dispositivos conectados: a depuração aberta facilita a instalação de software indesejado. 3) Verifique periodicamente os apps instalados (ajustes → aplicativos) e remova tudo o que não reconhece; use ferramentas de reputação como o Google Play Protect. 4) Faça cópias de segurança e mantenha uma imagem recente dos dados importantes se necessário um restabelecimento da fábrica. 5) Para empresas: aplique políticas MDM que bloqueem a instalação de apps não aprovadas e restrinjam modos de desenvolvedor em dispositivos corporativos.

Para pesquisadores e profissionais de segurança, o caso levanta ainda uma discussão sobre práticas de divulgação responsável. OnePlus declarou que a decisão final sobre quando publicar vulnerabilidades lhe corresponde – uma postura que Moorats reproduzia em sua troca e que motivou a ameaça de ações legais se publicava – e que as normas europeias obrigam a aceitar e corrigir relatórios, mas não permitiriam a divulgação por pesquisadores sem o consentimento do fabricante. Essa interpretação legal é controversa entre a comunidade de segurança, que costuma defender divulgações coordenadas com prazos razoáveis se o fornecedor não aplicar adesivos. Para orientação sobre boas práticas de divulgação existe material público de organismos como ENISA: ENISA — Coordinated Vulnerability Disclosure, e para aspectos técnicos do Android e mitigações de segurança, consultar a documentação oficial: Android Security — source.android.com.

Finalmente, se você acredita que seu dispositivo OnePlus ou OPPO pode estar comprometido ou instalou aplicações de origem duvidosa, considere reinstalar o sistema a partir da imagem oficial ou restaurar a valores de fábrica e, se possível, esperar o aviso e adesivo do fabricante antes de voltar a instalar aplicativos fora da loja oficial. Também é aconselhável manter-se atento a canais oficiais da OnePlus para um aviso de segurança e adesivo: a empresa dispõe de um site de suporte e políticas de segurança onde devem ser publicadas atualizações e procedimentos de mitigação (por exemplo, seu centro de segurança ou suporte técnico) OnePlus Support & Security.

O caso destaca uma realidade recorrente em dispositivos Android com camadas de fabricante: qualquer código adicional que seja executado com privilégios elevados multiplica a superfície de ataque. Até os fornecedores publicarem correções e listas de modelos afetados, a melhor defesa é a higiene digital do usuário e, para organizações, políticas técnicas que limitem instalações e privilégios.