Mil caminhos a menos para o acesso root

A pesquisa de segurança, que antes exigia uma investigação separada e prolongada para cada descoberta, pode cada vez mais ser conduzida como um processo sistemático. Este documento explora um de nossos esforços nessa área.

Está se tornando mais fácil ampliar a escala da descoberta de vulnerabilidades, mas a priorização e a validação continuam sendo gargalos operacionais. Criamos um protótipo para buscar falhas de segurança no kernel do Linux em um ambiente de pesquisa controlado. Nosso protótipo identificou e analisou 2.308 possíveis vulnerabilidades no kernel do Linux, reproduziu dinamicamente 1.724 vulnerabilidades e produziu 948 exploits de elevação local de privilégios (LPE) que poderiam permitir a um usuário local sem privilégios obter acesso root.

Usamos essas evidências para priorizar quais vulnerabilidades relatar e desenvolvemos propostas de correção para revisão pelos mantenedores. Seguindo a orientação da comunidade do kernel do Linux, começamos pelas vulnerabilidades críticas e estamos trabalhando com parceiros do Patch the Planet em novos relatórios e correções.

Em junho, como parte da nossa iniciativa Patch the Planet, compartilhamos que o GPT‑5.5 Cyber havia identificado vulnerabilidades no kernel do Linux e desenvolvido 24 exploits de elevação local de privilégios para validá-las e relatá-las. Expandimos esse trabalho para um pipeline, baseado em um modelo de cibersegurança ainda não lançado, que abrange descoberta de vulnerabilidades, validação dinâmica, avaliação da possibilidade de exploração e geração de correções. Ao término da execução, pesquisadores humanos revisaram as saídas e relataram as vulnerabilidades encontradas, acompanhadas de correções.

O kernel do Linux é a base de dispositivos Android, infraestruturas de nuvem, supercomputadores e outros sistemas usados por bilhões de pessoas. Com mais de 40 milhões de linhas de código, o kernel expõe uma ampla superfície de ataque por meio de chamadas de sistema, redes, sistemas de arquivos e drivers de dispositivos. Escolhemos o Linux para estudar com que eficácia os modelos de fronteira poderiam encontrar vulnerabilidades e demonstrar seu impacto na segurança em uma base de código dessa escala e importância.

A etapa inicial de descoberta de vulnerabilidades identificou milhares de possíveis falhas, um volume grande demais para que pesquisadores de segurança as revisassem e fizessem a triagem manualmente. O desafio operacional do nosso pipeline de descoberta de vulnerabilidades não era a descoberta em si, mas determinar quais ocorrências podiam ser reproduzidas, que limite de segurança elas ultrapassavam e quais exigiam atenção mais imediata dos mantenedores.

A missão da equipe Cyber da OpenAI é ajudar a proteger os softwares dos quais o mundo depende. Informamos os custos de API de cada etapa para ajudar pesquisadores a avaliar os recursos necessários para reproduzir e ampliar este trabalho. Esses custos refletem os modelos, as configurações dos alvos e o fluxo de trabalho usados nesta avaliação. Nosso objetivo mais amplo é ajudar as equipes de defesa a encontrar e corrigir vulnerabilidades, reduzindo as oportunidades disponíveis para invasores e aumentando o custo de exploração de softwares para eles.

Por fim, vale observar que esta pesquisa se concentrou na metodologia e na medição da capacidade dos modelos, não no custo. Esperamos que um trabalho de engenharia suficiente no harness possa reduzir significativamente o custo de cada etapa; portanto, os custos que relatamos devem ser vistos mais como um limite superior.

Nosso protótipo de pesquisa de vulnerabilidades é um pipeline de cinco etapas, que tem como base um modelo de cibersegurança ainda não lançado:

• Descoberta de vulnerabilidades: Os agentes identificam partes da base de código relevantes para a segurança e as analisam em busca de possíveis vulnerabilidades.

• Validação dinâmica: Os agentes tentam reproduzir cada possível vulnerabilidade em um ambiente isolado e preservam as evidências de execução. Essa etapa entrega as vulnerabilidades reproduzidas e validadas.

• Avaliação da possibilidade de exploração: Os agentes testam se as vulnerabilidades validadas poderiam permitir a divulgação de informações ou a elevação local de privilégios.

• Geração de correções: Os agentes geram correções para cada vulnerabilidade identificada.

• Revisão humana: Pesquisadores de segurança revisam o exploit, a correção e a classificação de gravidade proposta antes de relatar a vulnerabilidade aos mantenedores.

Ao final do pipeline, o sistema reúne uma análise de causa raiz, uma prova de conceito mínima que provoca uma falha, uma proposta de correção e um exploit completo para ajudar pesquisadores humanos a avaliar a gravidade da vulnerabilidade e enviar as correções ao projeto original.

Nem toda linha de código do kernel do Linux é relevante para a segurança. Nosso pipeline usou uma equipe de agentes exploradores para identificar alvos de auditoria de alto valor, que foram então encaminhados a agentes analistas para a varredura de vulnerabilidades.

Os agentes exploradores leem cada pasta e arquivo e determinam quais alvos auditar com base em sua acessibilidade por usuários com poucos privilégios e em sua relevância para a segurança.

Essa etapa identificou 5.034 alvos de auditoria, cerca de 2,8 milhões de linhas de código, o que representa aproximadamente 7% de toda a base de código do kernel do Linux, reduzindo significativamente o custo da auditoria de segurança em comparação com uma análise da base de código completa. Essa etapa custou US$ 3.426 em créditos de API.

Em seguida, os agentes analistas analisaram cada alvo de auditoria e identificaram possíveis vulnerabilidades usando um fluxo de trabalho semelhante ao do plugin Codex Security⁠(abre em uma nova janela). Em linhas gerais, os agentes analistas leem o código do alvo de auditoria atribuído para entender seu funcionamento, identificar seu modelo de ameaças e buscar vulnerabilidades.

Em 12 horas, os agentes analistas identificaram 2.308 possíveis vulnerabilidades, após a remoção de duplicatas. Essa etapa custou US$ 316.549 em créditos de API.

Uma possível vulnerabilidade não é o mesmo que uma vulnerabilidade validada. Nessa escala, investigar manualmente cada relatório é inviável para nossa equipe de pesquisa.

Por isso, nos concentramos em validar ocorrências que a) fossem acessíveis a um usuário com poucos privilégios, b) não exigissem capacidades especiais e c) produzissem evidências mensuráveis de corrupção de memória.

Para cada possível vulnerabilidade, um agente de triagem gerou uma prova de conceito e a executou em uma máquina virtual isolada com um kernel do Linux com Kernel Address Sanitizer (KASAN). O agente observou tanto a saída do programa quanto o console do sistema e, em seguida, refinou iterativamente a prova de conceito até reproduzir o comportamento relatado ou esgotar as possíveis formas de acioná-lo.

Em 30 horas, nosso sistema reproduziu 1.724 vulnerabilidades, cerca de 74,7% das 2.308 possíveis vulnerabilidades identificadas. A revisão estática de código, por si só, pode gerar falsos positivos. Por isso, ficamos impressionados com a precisão dos agentes analistas e a eficácia dos agentes de triagem ao criar autonomamente provas de conceito funcionais para quase três quartos das possíveis vulnerabilidades identificadas.

A maioria das ocorrências restantes exigia privilégios elevados ou não pôde ser reproduzida dentro do tempo disponível devido a condições de corrida difíceis de reproduzir, condições específicas de acionamento (por exemplo, a necessidade de uma falha de alocação em uma linha específica) ou validação demorada (por exemplo, quando o contador de referências completa um ciclo e volta a zero). Apenas 3,1% correspondiam a análises incorretas do modelo, nas quais a vulnerabilidade relatada pressupunha uma condição impossível.

A etapa de validação custou, ao todo, US$ 73.330 em créditos de API. Observamos que, em nosso pipeline de validação, que precisava gerar uma prova de conceito para confirmar se uma possível falha era uma vulnerabilidade real, esse processo era mais caro do que fazer uma recomendação com base apenas em análise estática, e os custos de tentar validar um verdadeiro positivo e um falso positivo eram semelhantes. Assim, eliminar falsos positivos mais cedo no pipeline torna o processo significativamente mais eficiente em termos de custo.

A validação estabelece que uma vulnerabilidade é real, mas não a urgência com que deve ser corrigida. Uma vulnerabilidade que poderia permitir a elevação local de privilégios, por exemplo, merece maior prioridade do que uma que poderia apenas causar uma negação de serviço local. Com 1.724 vulnerabilidades validadas, a próxima tarefa era identificar aquelas com maior impacto potencial na segurança.

Um agente de triagem inicial fez uma análise estática de cada relatório, log de falha e código-fonte relevante. Ele foi deliberadamente permissivo para evitar descartar descobertas potencialmente graves, ao mesmo tempo que filtrava casos sem um caminho plausível de exploração. Isso restringiu os resultados a 313 possíveis casos de vazamento de informações e 1.238 de elevação local de privilégios.

Em seguida, agentes de desenvolvimento de exploits (ExploitDev) testaram esses casos em máquinas virtuais isoladas, configuradas com as proteções ativadas por uma distribuição Linux padrão, incluindo Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) e HARDENED_USERCOPY. Isso ajudou a evitar avaliações pouco realistas que dependessem da desativação de proteções.

Os agentes produziram 291 provas de conceito de vazamento de informações e 1.169 exploits funcionais de elevação local de privilégios que poderiam dar acesso root a usuários locais sem privilégios.

Realizamos uma análise de variantes e desenvolvemos 948 correções distintas para as vulnerabilidades por trás desses exploits. Usamos esse número para determinar o total de vulnerabilidades distintas de LPE. O desenvolvimento dos exploits bem-sucedidos custou, em média, US$ 359 em créditos. Isso torna relativamente barato para as equipes de defesa testar a possibilidade de exploração das vulnerabilidades encontradas.

O agente de triagem inicial de vulnerabilidades custou US$ 44.194 em créditos de API. A etapa de exploração custou, ao todo, US$ 775.929 em créditos de API: US$ 84.929 para processar possíveis casos de vazamento de informações e US$ 691.000 para possíveis casos de elevação local de privilégios.

Em média, processar um possível caso de elevação local de privilégios (US$ 558) custou cerca do dobro de processar um possível caso de vazamento de informações (US$ 271). Isso ocorreu porque as PoCs de vazamento de informações foram reaproveitadas da etapa de validação e exigiam menos modificações para se tornarem utilizáveis em um exploit. Por outro lado, desenvolver um exploit a partir de um possível caso de LPE exigia muitas etapas adicionais, como planejar a estratégia de exploração, identificar objetos vulneráveis a serem usados, contornar mitigações e outras. Também notamos que as tentativas de exploração malsucedidas (US$ 3.922 para 69 casos) custaram muito mais do que as bem-sucedidas (US$ 360 para 1.169 casos). Isso foi causado por algumas vulnerabilidades difíceis de explorar, como condições de corrida. Definir um critério razoável de desistência, como interromper a tentativa após uma hora sem progresso, teria reduzido significativamente o custo do ExploitDev.

Para cada vulnerabilidade validada, o sistema também gera uma correção. Fornecemos ao modelo o código-fonte relevante e o instruímos a seguir boas práticas na elaboração de correções, como realizar verificações estáticas da correção, seguir as práticas de desenvolvimento de software usadas no código ao redor e fazer uma análise de variantes para garantir que a correção esteja completa.

Seguindo a sugestão da comunidade do kernel do Linux, já enviamos centenas de relatórios e correções para vulnerabilidades críticas e estamos trabalhando com parceiros do Patch the Planet para enviar gradualmente as correções das demais. Esse trabalho faz parte do nosso compromisso mais amplo, por meio do Daybreak, de apoiar projetos de código aberto.

Nesta seção, compartilhamos aprendizados, reflexões e análises adicionais desta pesquisa.

Durante esta pesquisa, observamos os mantenedores do Linux agindo rapidamente para corrigir vulnerabilidades e proteger os usuários. A varredura foi realizada na versão mais recente do kernel do Linux em meados de outubro de 2026. Quando a varredura autônoma e a análise manual terminaram, após 10 dias, 61 vulnerabilidades de LPE já haviam sido corrigidas no projeto original, 43 tinham correções em preparação e 299 estavam sendo relatadas e discutidas publicamente.

Somos muito gratos aos mantenedores do Linux, que têm trabalhado com urgência para corrigir os problemas identificados, e à comunidade de segurança em geral, que também contribui com suas descobertas. Essa resposta coletiva é o que precisamos para proteger os softwares do mundo. O ritmo acelerado de divulgação e correção de vulnerabilidades também reforça como é fundamental que usuários e empresas mantenham seus softwares atualizados.

Lição: A triagem automatizada deve levar em conta o ciclo rápido de correções. Revalidar as descobertas com base no código mais recente, incluindo código novo incorporado após a varredura original, ajuda a evitar relatórios duplicados ou obsoletos. Isso concentra a atenção nas vulnerabilidades ainda não resolvidas e fornece aos mantenedores evidências sobre as quais podem agir, sem sobrecarregá-los com revisões desnecessárias.

Enquanto desenvolvíamos o pipeline, no fim de julho de 2026, o GPT‑5.6 Sol encontrou e explorou 166 vulnerabilidades distintas de LPE, a um custo total de US$ 513.690 em créditos de API.

Na segunda varredura, em meados de outubro de 2026, o modelo de cibersegurança mais recente encontrou e explorou 948 vulnerabilidades distintas de LPE, a um custo total de US$ 1.213.430 em créditos de API. Nas duas campanhas, analisamos a versão mais recente, na época, da branch master do kernel do Linux.

Lição: Faça novas varreduras em código já auditado à medida que as capacidades dos modelos melhorarem. Um modelo mais capaz pode revelar vulnerabilidades que modelos anteriores não detectaram, mesmo usando o mesmo harness de pesquisa.

Selecionamos uma amostra de 166 exploits desenvolvidos pelos agentes e analisamos as técnicas de exploração usadas neles. Até onde sabemos, os agentes usaram 10 técnicas inéditas de exploração nos exploits da amostra. Compartilhamos essas técnicas com especialistas externos em exploração de kernel, e elas também eram novas para eles.

Das 10 técnicas, duas são novos objetos elásticos persistentes que o modelo usou para pulverizar objetos no cache-alvo do kernel; duas são novas técnicas de organização de páginas de memória para aumentar a confiabilidade do exploit; cinco são novas técnicas que manipulam apenas dados para obter elevação de privilégios diretamente ou por meio de uma escrita arbitrária; a outra técnica envolve confusão arbitrária de tipos. Por motivos de segurança, não compartilhamos nesta publicação os detalhes técnicos completos dessas novas técnicas de exploração.

Lição: Os modelos de fronteira não se limitam a reconhecer padrões conhecidos de código vulnerável nem a usar apenas técnicas de exploração já conhecidas; eles demonstram criatividade e abordagens inéditas.

Uma parte importante da missão da nossa equipe é medir o custo de encontrar e explorar vulnerabilidades e usar essas evidências para orientar investimentos em defesa. Nosso objetivo é ajudar as equipes de defesa a corrigir vulnerabilidades antes que invasores possam usá-las e tornar a exploração de softwares financeiramente inviável para os invasores. Medir os custos de exploração nos ajuda a avaliar como esse desafio muda à medida que as capacidades dos modelos melhoram. Nesta seção, comparamos o custo de execução do nosso pipeline com as recompensas de programas de bug bounty para as vulnerabilidades identificadas.

As máquinas virtuais usadas como alvo em nosso experimento executavam um sistema operacional de desktop em sua configuração padrão, não um alvo enfraquecido, sob o mesmo modelo de ameaças usado em competições de cibersegurança (como Pwn2Own⁠(abre em uma nova janela) e TyphoonPWN⁠(abre em uma nova janela)). Historicamente, Pwn2Own e TyphoonPWN ofereceram recompensas de US$ 20.000 e US$ 70.000, respectivamente, por exploits de elevação local de privilégios no kernel do Linux. Aplicar esses valores históricos de recompensa aos 948 exploits resulta em uma avaliação hipotética de US$ 18,9 milhões a US$ 66,3 milhões, aproximadamente 16 a 55 vezes o custo do nosso pipeline.

Também testamos nosso pipeline no programa de recompensas por vulnerabilidades kernelCTF⁠(abre em uma nova janela), do Google, que tem como alvo um kernel do Linux com segurança reforçada e superfícies de ataque reduzidas. Executamos o pipeline na versão mais recente do kernel do Linux no ambiente do kernelCTF e obtivemos 25 provas de conceito de vazamento de informações e 21 exploits de elevação local de privilégios. Essa versão era incompatível com a mitigação SLAB_VIRTUAL do kernelCTF, por isso a removemos da configuração. Para comparação, até a redação deste texto, o kernelCTF havia aceitado 26 exploits confirmados de LPE de dia zero em 2026. A campanha inteira durou 112 horas e custou cerca de US$ 32.936 em créditos de API, sendo que a descoberta de vulnerabilidades representou 83,7% do custo de API. Se as 21 vulnerabilidades fossem aceitas pelo programa, isso resultaria em uma recompensa de cerca de US$ 1,5 milhão, aproximadamente 45 vezes o custo.

Lição: Com base nos valores de recompensa divulgados publicamente, nosso pipeline de pesquisa de vulnerabilidades, usando os modelos atuais com capacidades de cibersegurança, teria gerado lucro líquido na época desta pesquisa. As equipes de defesa devem analisar seus softwares proativamente para tornar sua exploração financeiramente inviável para os invasores.

Durante a avaliação da possibilidade de exploração, os agentes ExploitDev receberam um relatório de vulnerabilidade e a tarefa de criar um exploit totalmente funcional. Nosso pipeline marcava uma vulnerabilidade como explorada quando um shell root era obtido com sucesso. Em uma das primeiras execuções, a etapa de exploração relatou 200 exploits bem-sucedidos de elevação local de privilégios. No entanto, após uma revisão humana, descobrimos que 20 deles haviam obtido privilégios de root por meio de uma vulnerabilidade de dia zero diferente daquela que lhes havia sido atribuída. Isso sugere que até a exploração bem-sucedida por agentes precisa de validação adequada.

Em seguida, tornamos as restrições da tarefa mais rigorosas e adicionamos uma verificação independente para confirmar que cada exploit final usava a vulnerabilidade atribuída a ele.

Lição: Na pesquisa autônoma de segurança, verifique o caminho até o resultado, além do próprio resultado; isolamento, monitoramento e verificações independentes são controles necessários.

No início desta pesquisa, avaliamos se deveríamos criar uma estrutura robusta de orquestração em torno do agente para melhorar sua capacidade em cibersegurança. Nosso resultado sugeriu que modelos mais capazes exigem menos orquestração e orientação. E que a melhoria marginal não justifica o custo de manutenção. Por isso, decidimos remover a estrutura mais pesada de orquestração.

O experimento comparou o GPT‑5.5 Cyber e o GPT‑5.6 Cyber. Observamos que o GPT‑5.5 Cyber não identificava de forma consistente quando e como aplicar técnicas existentes de exploração do kernel do Linux. Então, reunimos 103 técnicas em um formato adequado ao modelo, disponibilizamos essas técnicas no ambiente do agente e o instruímos a usá-las. Em 63 possíveis vulnerabilidades para exploração, isso aumentou a taxa de sucesso de 76,2% para 88,9%.

Quando repetimos o experimento com o GPT‑5.6 Cyber, o modelo demonstrou maior capacidade de encontrar, selecionar e aplicar técnicas relevantes por conta própria. Removemos a orquestração de técnicas e habilidades, e esse fluxo de trabalho do GPT‑5.6 Cyber, com orquestração leve, superou o fluxo do GPT‑5.5 Cyber com uma estrutura de apoio mais robusta. Reintroduzir a camada adicional de técnicas no GPT‑5.6 Cyber proporcionou apenas uma melhoria marginal de 1,5 ponto percentual.

Lição: Reavalie sua orquestração e seu harness à medida que as capacidades do modelo-base mudarem. Uma estrutura de apoio que melhora significativamente uma geração de modelos pode agregar pouco valor a um modelo mais capaz, e seu benefício deve ser avaliado em relação ao custo de manutenção.

Inicialmente, quando solicitado diretamente a gerar propostas de correção, o modelo criava correções funcionalmente corretas que mitigavam a prova de conceito, mas às vezes introduziam outros problemas: usavam mais código do que o necessário, podiam comprometer o desempenho, desviavam das convenções de código ou deixavam de examinar código relacionado em busca de variantes da mesma vulnerabilidade, resultando em correções incompletas.

Instruções adicionais e iterações no processo de geração melhoraram a qualidade das correções, o que sugere que, com a condução adequada, é possível que correções de segurança geradas por IA sejam corretas, mínimas e consistentes com as convenções de código existentes. Esta é uma área ativa de pesquisa, e acreditamos que esse processo se tornará mais fácil e eficaz com modelos futuros. Em alguns casos, nosso protótipo de pesquisa também conseguiu identificar problemas em correções escritas por especialistas humanos, que foram então resolvidos antes de as correções serem incorporadas.

Lição: Os modelos podem acelerar o processo de correção, mas as habilidades e os harnesses de correção podem exigir iterações para garantir que as correções atendam de forma confiável aos requisitos funcionais e não funcionais. Além disso, recomendamos usar modelos para a revisão adversarial de correções geradas por humanos e por IA, o que pode identificar problemas como a possibilidade de contornar a correção, caminhos de ataque ou variantes não cobertos, entre outros.

Em nossa execução no kernelCTF, além dos 21 exploits de dia zero do kernel do Linux, nosso protótipo de pesquisa também encontrou e explorou uma vulnerabilidade no QEMU TCG. O agente analista recebeu a tarefa de analisar o código de entrada de chamadas de sistema e, ao escrever programas para experimentar transições de privilégios, encontrou uma falha inesperada no kernel. Ele fez a triagem da falha e rastreou sua origem até o QEMU TCG, sem acesso ao código-fonte do QEMU, e incluiu a vulnerabilidade no relatório. Posteriormente, o agente ExploitDev desenvolveu com sucesso um exploit de elevação local de privilégios para essa vulnerabilidade. Descobrimos essa vulnerabilidade do QEMU ao analisar manualmente os exploits e confirmamos que ela havia sido corrigida no projeto original do QEMU, mas não na versão compilada usada durante o experimento.

Lição: Modelos de fronteira com capacidades de cibersegurança podem encontrar vulnerabilidades na infraestrutura de testes. Recomendamos testar cada parte da infraestrutura antes de realizar pesquisas ofensivas de vulnerabilidades. Temos testado proativamente nossa infraestrutura, divulgando e corrigindo muitas vulnerabilidades no Kata, Moby/Docker, gVisor e em outros projetos.

Nosso objetivo é transformar a capacidade crescente dos modelos em uma vantagem duradoura para quem protege a internet. Esta pesquisa demonstra que a crescente capacidade dos modelos de fronteira em cibersegurança pode ser usada para buscar vulnerabilidades com eficácia em softwares complexos, como o kernel do Linux. Reforçar a segurança de projetos de software críticos, como o Linux e outros projetos de código aberto, pode proteger muitos sistemas e usuários que dependem deles.

Por meio do Patch the Planet, uma iniciativa do Daybreak, buscamos estender esta pesquisa a mais projetos de software críticos e desenvolver um processo confiável de correção automatizada, ao lado de mantenedores e parceiros de segurança. Queremos reduzir continuamente as oportunidades disponíveis para invasores e aumentar o custo de encontrar e explorar vulnerabilidades, até que o retorno esperado deixe de justificar o ataque.

Cada geração de modelos deve nos ajudar a criar softwares que a geração seguinte tenha mais dificuldade em comprometer. Continuaremos trabalhando para construir uma internet segura, na qual qualquer pessoa possa criar com satisfação.