GrapheneOS corrige vazamento de VPN no Android que o Google disse que não corrigiria

• GrapheneOS corrigiu em uma nova atualização uma vulnerabilidade de desvio de VPN que podia expor o endereço IP real mesmo com “Always-On VPN” e “Block connections without VPN” ativados no Android
• A vulnerabilidade se originava no recurso de encerramento de conexão QUIC da pilha de rede do Android 16, permitindo que um app comum registrasse payloads UDP no system_server usando apenas permissões padrão
• Quando o socket UDP do app era destruído, o system_server, que é privilegiado, enviava diretamente o payload armazenado pela interface física de rede, em vez do túnel VPN, contornando a proteção de bloqueio da VPN
• O Google classificou o problema como “Won’t Fix (Infeasible)” e “NSBC”, mantendo a posição de que ele não atende aos critérios dos alertas de segurança do Android
• No release 2026050400, o GrapheneOS desativou a “registerQuicConnectionClosePayload optimization” e também incluiu o patch de segurança do Android de maio de 2026, melhorias no hardened_malloc, atualizações do kernel Linux e correção retroportada para o libpng CVE-2026-33636

---

Como a vulnerabilidade funcionava

• Segundo a análise técnica de Yusuf, a API vulnerável permitia que um app comum, com apenas as permissões concedidas automaticamente INTERNET e ACCESS_NETWORK_STATE, registrasse payloads UDP arbitrários no system_server
• Depois, quando o socket UDP do app era destruído, o processo privilegiado system_server do Android transmitia o payload armazenado diretamente pela interface física de rede do dispositivo, e não pelo túnel VPN
• Como o system_server opera com permissões de rede elevadas e está isento das restrições de roteamento da VPN, esse pacote contornava completamente a proteção de bloqueio da VPN do Android
• O pesquisador de segurança lowlevel/Yusuf demonstrou a vulnerabilidade em um Pixel 8 com Android 16, com o Proton VPN e o modo de bloqueio do Android ativados ao mesmo tempo
• O app conseguia vazar o endereço IP público real do dispositivo para um servidor remoto mesmo com a proteção da VPN totalmente ativa

Causa e tratamento dado pelo Google

• O Google introduziu um recurso para permitir que aplicativos encerrem sessões QUIC corretamente quando um socket é destruído de forma inesperada
• A implementação aceitava payloads arbitrários, sem verificar se aquele payload era de fato um frame legítimo de QUIC CONNECTION_CLOSE
• A implementação também não verificava originalmente se o aplicativo estava restrito apenas a tráfego via VPN
• O pesquisador relatou o problema à equipe de segurança do Android, mas o Google o classificou como “Won’t Fix (Infeasible)” e “NSBC” (Not Security Bulletin Class)
• O Google concluiu que o problema não atende aos critérios para inclusão nos alertas de segurança do Android
• O pesquisador pediu reavaliação, argumentando que qualquer app com permissões padrão poderia vazar informações de rede identificáveis, mas o Google manteve a posição e autorizou a divulgação em 29 de abril

Atualização do GrapheneOS e mitigação

• O GrapheneOS é um sistema operacional baseado em Android, com foco em privacidade e segurança, desenvolvido principalmente para dispositivos Google Pixel, usado por pessoas que querem sandboxing de aplicativos mais forte, mitigação de exploits e menor dependência dos serviços do Google
• No release 2026050400, o GrapheneOS desativou completamente essa otimização para impedir o vazamento pela VPN
• Yusuf afirmou que o GrapheneOS concluiu a distribuição da correção em menos de uma semana
• Além da correção do vazamento de VPN, o release mais recente inclui todo o nível de patch de segurança do Android de maio de 2026
• A atualização inclui várias melhorias no hardened_malloc, atualizações do kernel Linux em toda a linha dos branches 6.1, 6.6 e 6.12 do Android, e uma correção retroportada para o CVE-2026-33636 do libpng
• Um novo build do navegador Vanadium e restrições ampliadas para Dynamic Code Loading também são fornecidos
• Usuários do Android padrão podem mitigar temporariamente o problema desativando a flag DeviceConfig close_quic_connection via ADB
• Esse contorno exige acesso de desenvolvedor
• Se o Google remover essa flag de recurso em atualizações futuras, essa mitigação pode deixar de ser viável

[GN⁺]

Comentários do Hacker News

• Se o system_server opera com altos privilégios de rede e fica isento das restrições de roteamento da VPN, então no Android VPN na prática não é VPN nenhuma
  Independentemente desse bug, fico curioso se outros sistemas operacionais fechados também funcionam assim

  • No iOS é a mesma coisa, e pelo que sei, para contornar isso é necessária uma licença enterprise para mais de 250 dispositivos
    Mullvad e outros já trataram desse problema há muito tempo
  • Termos como “private” ou “trust” têm significados diferentes no mundo da computação e nas convenções humanas
    O que me preocupa é que as pessoas veem palavras com a mesma grafia e não percebem a diferença de contexto, estendendo por engano a confiança humana ao modelo de confiança dos computadores
  • Já houve casos no macOS em que apps do próprio sistema conseguiam contornar uma VPN sempre ativa
    Não sei se existia uma vulnerabilidade ou brecha que permitia enviar tráfego diretamente para destinos arbitrários
  • Fico curioso para saber quão difícil é corrigir o system_server e outras rotas de escape

• Assim como o Manifest V3, impedir espionagem não está alinhado aos interesses do Google
  Esse tipo de restrição prejudica o modelo de negócios deles

• O motivo técnico de isso ser grave é que o vazamento ocorre a partir do processo privilegiado system_server
  O próprio modo de bloqueio do Android promete explicitamente que nenhum tráfego contornará a VPN. Se o próprio sistema envia pacotes pela interface física, essa promessa está sendo quebrada no nível do kernel, não no espaço do usuário, então é difícil dizer que “não é caso para aviso de segurança”

• Se o Google autorizou a divulgação em 29 de abril, surpreende que o embargo tenha sido mantido e a distribuição da correção tenha ficado para maio
  Não entendo por que não divulgaram imediatamente

  • Provavelmente para não prejudicar a relação com o Google como fornecedor
    Queiram ou não, o GrapheneOS depende do Android controlado pelo Google

• Entendo que existam razões comerciais ruins, mas não sei como dá para manter a autoestima ao classificar vazamento de VPN como algo que não é problema de segurança

  • Depende de como você enxerga o papel de uma VPN
    Originalmente, VPN servia para acessar uma rede privada ou corporativa por outra rede, como conectar escritórios entre si ou acessar o escritório de casa. Só depois ela passou a ser vista como uma espécie de ferramenta de segurança
    Se você olha para o código de VPN como algo do tipo “o celular precisa conseguir acessar a impressora do escritório via 5G”, isso pode parecer um bug pequeno, como uma conexão QUIC que não foi encerrada corretamente. Já se você pensa “esse túnel WireGuard precisa proteger minha identidade custe o que custar” ou “isso deveria ser uma cópia exata de todo o tráfego que entrou e saiu da internet”, então é um problema grande
    Eu diria que a VPN do Android, ou praticamente qualquer VPN, nunca foi projetada como mecanismo de privacidade ou segurança. Especialmente contra apps que podem executar código no dispositivo, e o próprio aparelho também faz várias interações de rede, inclusive dentro do chip do modem
    O Google errou ao encerrar o bug, mas dá para entender por que não o considera um bug de segurança no programa de bug bounty
  • Essa pergunta só faz sentido se você assumir que há autoestima a preservar
  • Do ponto de vista do Google, isso não é bug, é feature
    O Google é uma empresa de publicidade e também um contratado de ataque, então usuários de VPN vazando pacotes traz vantagem para eles pelos dois motivos
  • É para isso que eles recebem dinheiro
  • Não acho que eu conseguiria trabalhar no Google considerando divulgação indesejada de dados pessoais como um problema de segurança

• Isso também lembra o Meta removendo a criptografia de ponta a ponta
  É algo mais próximo de “não, queremos ver tudo o que você diz e faz”

• Queria saber uma boa forma de conseguir um telefone com GrapheneOS
  Tenho vontade de testar o GrapheneOS, mas ainda hesito em comprar de fato um Pixel. Mesmo usados, normalmente passam de 300 dólares até na linha “a”, e aí já tem que voltar algumas gerações. Também tem a questão de o desbloqueio do bootloader ser possível. Ainda é difícil justificar gastar 449 dólares num Pixel 10a novo

  • Talvez não ajude agora, mas o GrapheneOS anunciou recentemente uma parceria com a Motorola, então imagino que daqui a um ano comecem a aparecer alguns dispositivos Motorola suportados
    Como referência, comprei um Pixel 10a por cerca de 300 dólares no lançamento do Google Fi
  • Melhor não comprar o Pixel 10a
    O Pixel 9a é praticamente o mesmo aparelho e ainda está à venda novo
  • Eu recomendaria a série Pixel 8 ou superior
    É mais garantido comprar novo em loja comum ou na Google Store, em vez de loja de operadora
    Usado é quase uma aposta por causa do problema de desbloqueio OEM, então vale conferir se a política de devolução é boa e verificar antes da compra se o desbloqueio OEM está acessível
  • Respondi em outra thread: https://news.ycombinator.com/item?id=48076522
    Basicamente, compre um dispositivo Pixel 6 ou posterior em que seja certo que o desbloqueio do bootloader é possível. Mas como o Pixel 6 em breve ficará só com suporte mínimo, eu recomendaria Pixel 7 ou posterior. A maioria dos usados não permite desbloqueio do bootloader
    Ou seja, o ideal é comprar direto do Google, ou pegar um anúncio no eBay com GrapheneOS/CalyxOS/LineageOS já instalado, ou então um aparelho em que o vendedor declare explicitamente que o desbloqueio do bootloader é possível
    Pessoalmente, se o vendedor ainda não falou isso, pedir para ele verificar o bootloader nunca me adiantou. Quase ninguém quer passar pelo processo de verificação, a resposta provavelmente será “não dá”, eles podem entender mal e responder apenas que é “desbloqueado para operadora”, ou simplesmente já estarem cansados desse tipo de pergunta
  • Também dá para esperar um pouco
    Há trabalho em andamento para suportar mais hardware de celulares, e por um tempo ficou no ar qual marca seria

• Comprei um Pixel 6 usado e barato para testar o GrapheneOS, mas não gostei muito
  Acho a experiência de uso do LineageOS bem melhor. A estrutura do gerenciador de pacotes parece estranha, tipo boneca russa. A “App Store” padrão só tem alguns programas básicos, e um deles é outro gerenciador de pacotes, o Accrescent, mas ainda há poucos apps, então você acaba precisando de mais outro gerenciador de pacotes. O pessoal do GrapheneOS parece preferir Obtainium a F-Droid, e isso também me parece uma decisão estranha
  Prefiro muito mais um gerenciador de pacotes totalmente open source, e existe valor real em compilar externamente a partir do código-fonte e, quando possível, de forma reproduzível, em vez de simplesmente confiar em pacotes do GitHub. O modelo de segurança do GrapheneOS me parece estranhamente centralizado. Já os supostos benefícios de privacidade e segurança são difíceis de avaliar por conta própria

  • É só baixar o F-Droid diretamente
    Não entendo essa insistência de que precisa existir obrigatoriamente uma loja de apps definitiva e pré-instalada
    Manter uma loja de apps dá tanto trabalho quanto manter um fork de Android, e considerando que já existem F-Droid, Play Store com Aurora Store, Obtainium e outras opções, é difícil culpar os desenvolvedores do GrapheneOS por não investirem um esforço enorme nisso
  • A App Store serve mais como um ponto de partida mínimo para decidir de onde baixar apps
    No estado padrão, há apenas o launcher e o sistema operacional mínimo, o que já basta para um minimalista
    Se quiser mais, o usuário decide para onde ir. Eu chamaria isso de dar poder ao usuário, enquanto parece que você chama de inconveniência. Nesse caso, talvez esse sistema operacional não seja para você
  • Um software ser livre ou open source não o torna inerentemente mais seguro ou mais privado
    “Open source” é, no fim das contas, apenas um termo de licenciamento
    A “App Store” do GrapheneOS serve para fornecer os apps mais básicos necessários para uso geral. O Accrescent é distribuído ali porque, como loja de aplicativos de verdade, segue a linha de base de segurança do Android, enquanto o F-Droid e a Aurora Store não seguem
    Não vejo grande valor na ideia de terceiros compilarem apps, como no F-Droid, para verificar comportamento malicioso. Essas verificações não são confiáveis e já foram burladas antes. Esse é um dos motivos pelos quais o WireGuard não está mais no F-Droid. Se você não confia o bastante num app para obtê-lo diretamente do desenvolvedor, então provavelmente não deveria usá-lo
    As vantagens de privacidade e segurança do GrapheneOS são projetadas para serem quase invisíveis ao usuário médio. Por exemplo, há um alocador de memória reforçado e extensões de marcação de memória para impedir bugs de corrupção de memória, além da possibilidade de instalar Google Play em sandbox para usar serviços do Google sem deixar o Google controlar o dispositivo inteiro
  • O GrapheneOS herdou a interface de usuário do Android Open Source Project, e vários forks Android de outros fabricantes, além do sistema padrão do Pixel, também se baseiam nisso
    A App Store do GrapheneOS existe para cumprir o papel de loja de apps primária exigido pelo AOSP. Ela também serve para atualizar apps primários separadamente das atualizações do sistema operacional e, em alguns casos, espelhar apps
    O Accrescent é espelhado porque tem foco em privacidade e segurança. No momento está em alpha e o envio de apps está fechado, mas deve abrir em breve
    O Google Play é espelhado para compatibilidade com apps que dependem do Google Play e para acesso à Play Store
    A comunidade do GrapheneOS prefere o Obtainium porque ele pode buscar apps assinados pelo desenvolvedor em lugares como o GitHub. O F-Droid assina e compila quase todos os apps do repositório principal com infraestrutura de build antiga e uma coordenação fraca
    O modelo de segurança do GrapheneOS herda o modelo de segurança do AOSP e o reforça ainda mais
  • Fico muito feliz que o CalyxOS tenha voltado a ganhar tração
    O GrapheneOS tem muitas implementações técnicas impressionantes, mas o pessoal do Calyx parece resolver muita coisa de um jeito mais simples e mais próximo do Android puro

• O GrapheneOS diz que, para “corrigir o vazamento de VPN”, desativou a otimização registerQuicConnectionClosePayload e praticamente neutralizou o vetor de ataque nos Pixels suportados
  Ou seja, o GrapheneOS “corrigiu” o vazamento desligando a otimização
  No passado, no HN já elogiaram o QUIC, e chegaram a dar voto negativo em comentários que perguntavam quem mais se beneficiava do QUIC. O uso do QUIC pode estar alinhado aos interesses de outros, mas para mim a troca não vale a pena, então eu bloqueio tráfego QUIC
  Em alguns casos, como no software distribuído pelo Google para Android, o QUIC vem ativado por padrão e às vezes nem há como desativá-lo

  • No GrapheneOS, o QUIC em si continua funcionando normalmente
    O que o GrapheneOS removeu foi apenas a forma de pedir ao sistema operacional para fechar automaticamente conexões QUIC em situações como quando o app morre. Do ponto de vista do servidor, isso é uma otimização, porque evita que a conexão fique aberta consumindo recursos até o tempo limite de inatividade e depois precise passar pelo encerramento; do ponto de vista do cliente, não é uma otimização
    Além disso, o GrapheneOS corrigiu cerca de mais 5 vazamentos de VPN e segue trabalhando em correções adicionais. A implementação atual de VPN no Android é por perfil, mas o perfil ainda não usa seu próprio namespace de rede, e por isso o resolvedor DNS e vários serviços centrais precisam tratar corretamente o suporte a VPN, o que a torna suscetível a vazamentos
    No futuro, eles pretendem melhorar a arquitetura de VPN para torná-la muito resistente a vazamentos. Também deve chegar suporte para executar apps ou grupos de apps em máquinas virtuais, o que pode oferecer proteção ainda mais forte
  • Isso significa que a rota de encerramento elegante de conexões QUIC foi exposta por meio de uma chamada inadequada ou passível de abuso, não que o GrapheneOS tenha desativado o QUIC por completo
    O QUIC em si é excelente, e isso está menos ligado a uma funcionalidade do protocolo e mais a uma funcionalidade do Google Android, um sistema operacional de vigilância
    Além disso, quando testei em um sistema anterior ao release mais recente, nem funcionava direito

• O Android puro é spyware e adware
  Antigamente a gente chamaria um software desses de malicioso e o removeria, mas agora virou o padrão

  • Todo mundo concorda, mas ninguém sabe qual é a solução
    Sabemos que 99% dos usuários não ligam para isso, então o único ponto de pressão seriam os fabricantes de celulares. Dá uma sensação de impotência não ter poder para influenciar ninguém com impacto real nessa área