Menos mil caminhos para o acesso root

A investigação de segurança, que antes exigia uma análise individual e prolongada de cada potencial vulnerabilidade, pode cada vez mais ser realizada de forma sistemática. Este documento explora um dos nossos esforços nesta área.

É cada vez mais fácil descobrir vulnerabilidades em grande escala, mas a definição de prioridades e a validação continuam a ser entraves operacionais. Criámos um protótipo para procurar falhas de segurança no kernel Linux num ambiente de investigação controlado. O nosso protótipo identificou e analisou 2 308 potenciais vulnerabilidades no kernel Linux, reproduziu dinamicamente 1 724 vulnerabilidades e produziu 948 exploits de elevação local de privilégios (LPE) que poderiam permitir a um utilizador local sem privilégios obter acesso root.

Usámos estas provas para definir a prioridade de comunicação das vulnerabilidades e desenvolvemos propostas de correção para revisão pelos responsáveis pela manutenção. Seguindo as orientações da comunidade do kernel Linux, começámos pelas vulnerabilidades críticas e estamos a trabalhar com os parceiros do Patch the Planet em mais relatórios e correções.

Em junho, no âmbito da nossa iniciativa Patch the Planet, partilhámos que o GPT‑5.5 Cyber tinha identificado vulnerabilidades no kernel Linux e desenvolvido 24 exploits de elevação local de privilégios para as validar e comunicar. Alargámos esse trabalho a um pipeline, assente num futuro modelo de cibersegurança, que abrange a descoberta de vulnerabilidades, a validação dinâmica, a avaliação da possibilidade de exploração e a geração de correções. Após a conclusão do processo, investigadores humanos reviram os resultados e comunicaram as vulnerabilidades encontradas, juntamente com as correções.

O kernel Linux está na base de dispositivos Android, infraestruturas de nuvem, supercomputadores e outros sistemas usados por milhares de milhões de pessoas. Com mais de 40 milhões de linhas de código, o kernel expõe uma ampla superfície de ataque através de chamadas de sistema, funcionalidades de rede, sistemas de ficheiros e controladores de dispositivos. Escolhemos o Linux para estudar a eficácia com que os modelos de fronteira poderiam encontrar vulnerabilidades e demonstrar o seu impacto na segurança numa base de código desta dimensão e importância.

A etapa inicial de descoberta de vulnerabilidades identificou milhares de potenciais falhas, demasiadas para os investigadores de segurança reverem e classificarem manualmente. O desafio operacional do nosso pipeline de descoberta de vulnerabilidades não era a descoberta em si, mas determinar que falhas podiam ser reproduzidas, que barreira de segurança ultrapassavam e quais mereciam atenção mais urgente dos responsáveis pela manutenção.

A missão da equipa de cibersegurança da OpenAI é ajudar a proteger o software de que o mundo depende. Apresentamos os custos de API de cada etapa para ajudar os investigadores a avaliar os recursos necessários para reproduzir e alargar este trabalho. Estes custos refletem os modelos, as configurações dos alvos e o fluxo de trabalho usados nesta avaliação. O nosso objetivo mais amplo é ajudar os defensores a encontrar e corrigir vulnerabilidades, reduzindo as oportunidades ao dispor dos atacantes e aumentando o custo de exploração do software.

Por fim, importa notar que esta investigação se centrou na metodologia e na medição da capacidade dos modelos, não no custo. Esperamos que um trabalho de engenharia suficiente sobre o harness possa reduzir significativamente o custo de cada etapa; por isso, os custos apresentados devem ser vistos sobretudo como um limite superior.

O nosso protótipo de investigação de vulnerabilidades é um pipeline de cinco etapas, assente num futuro modelo de cibersegurança:

• Descoberta de vulnerabilidades: Os agentes identificam as partes da base de código relevantes para a segurança e analisam-nas à procura de potenciais vulnerabilidades.

• Validação dinâmica: Os agentes tentam reproduzir cada potencial vulnerabilidade num ambiente isolado e preservam as provas recolhidas durante a execução. Este passo produz o conjunto de vulnerabilidades reproduzidas e validadas.

• Avaliação da possibilidade de exploração: Os agentes testam se as vulnerabilidades validadas podem permitir a divulgação de informação 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: Os investigadores de segurança revêm o exploit, a correção e o nível de gravidade proposto antes de os comunicar aos responsáveis pela manutenção.

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

Nem todas as linhas de código do kernel Linux são relevantes para a segurança. O nosso pipeline usou uma equipa de agentes exploradores para identificar alvos de auditoria de elevado interesse, que foram depois passados a agentes analistas para deteção de vulnerabilidades.

Os agentes exploradores percorrem cada pasta e ficheiro e determinam que alvos auditar com base na sua acessibilidade a utilizadores com poucos privilégios e na sua relevância para a segurança.

Esta etapa identificou 5 034 alvos de auditoria, cerca de 2,8 milhões de linhas de código, o que corresponde a aproximadamente 7% de toda a base de código do kernel Linux, reduzindo significativamente o custo da auditoria de segurança face a uma análise integral do código. Este passo custou 3 426 USD em créditos de API.

Em seguida, os agentes analistas analisaram cada alvo de auditoria e identificaram potenciais vulnerabilidades através de um fluxo de trabalho semelhante ao do plugin Codex Security⁠(abre numa nova janela). Em termos gerais, os agentes analistas leem o código do alvo de auditoria que lhes foi atribuído para compreender o seu funcionamento, identificar o seu modelo de ameaças e procurar vulnerabilidades.

Em 12 horas, os agentes analistas identificaram 2 308 potenciais vulnerabilidades, após a remoção de duplicados. Esta etapa custou 316 549 USD em créditos de API.

Uma potencial vulnerabilidade não é o mesmo que uma vulnerabilidade validada. A esta escala, investigar manualmente cada relatório é impraticável para a nossa equipa de investigação.

Por isso, concentrámo-nos em validar potenciais vulnerabilidades que a) fossem acessíveis a um utilizador com poucos privilégios, b) não exigissem capacidades especiais e c) produzissem provas mensuráveis de corrupção de memória.

Para cada potencial vulnerabilidade, um agente de triagem gerou uma prova de conceito e executou-a numa máquina virtual isolada com um kernel Linux com Kernel Address Sanitizer (KASAN). O agente observou tanto a saída do programa como a consola do sistema e foi aperfeiçoando a prova de conceito até reproduzir o comportamento descrito ou esgotar as formas possíveis de o desencadear.

Em 30 horas, o nosso sistema reproduziu 1 724 vulnerabilidades, cerca de 74,7% das 2 308 potenciais vulnerabilidades. A revisão estática do código, por si só, pode gerar falsos positivos. Por isso, ficámos impressionados com a precisão dos agentes analistas e com a eficácia dos agentes de triagem ao criarem autonomamente provas de conceito funcionais para quase três quartos das potenciais vulnerabilidades.

A maioria das restantes potenciais vulnerabilidades exigia privilégios elevados ou não foi reproduzida no tempo disponível, devido a condições de corrida difíceis, condições específicas de ativação (por exemplo, uma falha de alocação necessária numa linha específica) ou validações demoradas (por exemplo, o retorno a zero do contador de referências por transbordo). Apenas 3,1% refletiam uma análise incorreta do modelo, em que a vulnerabilidade descrita pressupunha uma condição impossível.

A etapa de validação custou, no total, 73 330 USD em créditos de API. Observámos que, no nosso pipeline de validação, que precisava de gerar uma prova de conceito para confirmar se uma potencial vulnerabilidade era real, este processo era mais dispendioso do que fazer uma recomendação baseada apenas na análise estática. Os custos de tentar validar um verdadeiro positivo e um falso positivo eram semelhantes. Assim, eliminar os falsos positivos mais cedo no pipeline torna o processo significativamente mais eficiente em termos de custos.

A validação estabelece que uma vulnerabilidade é real, mas não a urgência com que deve ser corrigida. Uma vulnerabilidade que possa permitir a elevação local de privilégios, por exemplo, merece maior prioridade do que outra que apenas possa causar uma negação de serviço local. Com 1 724 vulnerabilidades validadas, a tarefa seguinte era identificar as que tinham maior impacto potencial na segurança.

Um agente de triagem inicial fez uma análise estática de cada relatório, registo de falha e código-fonte relevante. Os seus critérios eram deliberadamente permissivos, para evitar descartar vulnerabilidades potencialmente graves, mas excluíam os casos sem uma via de exploração plausível. Isto restringiu os resultados a 313 potenciais fugas de informação e 1 238 potenciais elevações locais de privilégios.

Os agentes de desenvolvimento de exploits (ExploitDev) testaram depois essas potenciais vulnerabilidades 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. Isto ajudou a evitar avaliações irrealistas que dependessem da desativação das proteções.

Os agentes produziram 291 provas de conceito de fuga de informação e 1 169 exploits funcionais de elevação local de privilégios que poderiam dar acesso root a utilizadores locais sem privilégios.

Realizámos uma análise de variantes e desenvolvemos 948 correções distintas para as vulnerabilidades subjacentes a esses exploits. Usamos esse número para determinar o total de vulnerabilidades distintas de LPE. O desenvolvimento de exploits bem-sucedidos custou, em média, 359 USD em créditos. Isto torna relativamente pouco dispendioso para os defensores testar se as vulnerabilidades encontradas podem ser exploradas.

O agente de triagem inicial de vulnerabilidades custou 44 194 USD em créditos de API. A etapa de exploração custou, no total, 775 929 USD em créditos de API: 84 929 USD para processar potenciais fugas de informação e 691 000 USD para potenciais elevações locais de privilégios.

Em média, processar uma potencial elevação local de privilégios (558 USD) custou cerca do dobro de processar uma potencial fuga de informação (271 USD). Isto deve-se ao facto de as PoC de fuga de informação terem sido aproveitadas da etapa de validação e precisarem de menos alterações para poderem ser usadas num exploit. Por outro lado, desenvolver um exploit a partir de uma potencial vulnerabilidade de LPE exigia muitos passos adicionais, como planear a estratégia de exploração, identificar objetos vulneráveis a usar, contornar mitigações, entre outros. Também observámos que as tentativas de exploração malsucedidas (3 922 USD para 69 casos) custaram muito mais do que as bem-sucedidas (360 USD para 1 169 casos). Isto deveu-se a 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 progressos, 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 instruímo-lo sobre boas práticas de criação de correções, como realizar verificações estáticas da correção, seguir as práticas de desenvolvimento usadas no código envolvente e analisar variantes para garantir que a correção é completa.

Seguindo a sugestão da comunidade do kernel Linux, já enviámos centenas de relatórios e correções para vulnerabilidades críticas e estamos a trabalhar com os parceiros do Patch the Planet para enviar gradualmente correções para as restantes. Este trabalho integra o nosso compromisso mais amplo de apoio a projetos de código aberto no âmbito do Daybreak.

Nesta secção, partilhamos aprendizagens, reflexões e análises adicionais desta investigação.

Durante esta investigação, observámos a rapidez com que os responsáveis pela manutenção do Linux corrigem vulnerabilidades e protegem os utilizadores. A análise foi realizada sobre o kernel Linux mais recente em meados de outubro de 2026. Quando a análise autónoma e a análise manual terminaram, ao fim de 10 dias, 61 vulnerabilidades de LPE já tinham sido corrigidas no projeto original, 43 tinham correções em preparação e 299 estavam a ser comunicadas e discutidas publicamente.

Agradecemos profundamente aos responsáveis pela manutenção do Linux, que têm trabalhado com urgência para corrigir os problemas identificados, e à comunidade de segurança em geral, que também tem contribuído com as suas descobertas. É esta resposta coletiva que é necessária para proteger o software de todo o mundo. O ritmo acelerado de divulgação e correção de vulnerabilidades também sublinha a importância crucial de os utilizadores e as empresas manterem o software atualizado.

Lição principal: A triagem automática deve ter em conta o ciclo rápido de correções. Revalidar as potenciais vulnerabilidades face ao código mais recente, incluindo código integrado após a análise original, ajuda a evitar relatórios duplicados ou obsoletos. Isto concentra a atenção nas vulnerabilidades por resolver e fornece aos responsáveis pela manutenção provas que lhes permitem agir, sem acrescentar trabalho de revisão desnecessário.

Durante o desenvolvimento do pipeline, no final de julho de 2026, o GPT‑5.6 Sol encontrou e explorou 166 vulnerabilidades distintas de LPE, com um custo total de 513 690 USD em créditos de API.

Na segunda análise, em meados de outubro de 2026, o modelo de cibersegurança mais recente encontrou e explorou 948 vulnerabilidades distintas de LPE, com um custo total de 1 213 430 USD em créditos de API. Em ambas as campanhas, analisámos a versão mais recente do ramo master do kernel Linux à data.

Lição principal: Volte a analisar código já auditado à medida que as capacidades dos modelos melhoram. Um modelo mais capaz pode revelar vulnerabilidades que os modelos anteriores não detetaram, mesmo usando o mesmo harness de investigação.

Selecionámos uma amostra de 166 exploits desenvolvidos pelos agentes e analisámos as técnicas de exploração usadas. Tanto quanto sabemos, os agentes usaram 10 técnicas de exploração inéditas nos exploits da amostra. Partilhámos as técnicas de exploração com especialistas externos em exploração do kernel, que também não as conheciam.

Das 10 técnicas, duas consistem em novos objetos elásticos persistentes que o modelo usou para preencher a cache alvo do kernel com objetos; duas são novas técnicas de preparação de páginas de memória para melhorar a fiabilidade dos exploits; cinco são novas técnicas baseadas apenas em dados para obter elevação de privilégios diretamente ou através de uma escrita arbitrária; a outra técnica envolve confusão arbitrária de tipos. Por motivos de segurança, não partilhamos nesta publicação os detalhes técnicos completos destas novas técnicas de exploração.

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

Uma parte importante da missão da nossa equipa é medir o custo de encontrar e explorar vulnerabilidades e usar esses dados para orientar o investimento em defesa. O nosso objetivo é ajudar os defensores a corrigir vulnerabilidades antes que os atacantes as possam usar e tornar proibitivo o custo de explorar software para os atacantes. Medir os custos de exploração ajuda-nos a avaliar como esse desafio evolui à medida que as capacidades dos modelos melhoram. Nesta secção, comparamos o custo de execução do nosso pipeline com as recompensas dos programas de deteção de vulnerabilidades para as falhas identificadas.

As máquinas virtuais alvo da nossa experiência executavam um sistema operativo de computador pessoal sem alterações, e não um alvo enfraquecido, segundo o mesmo modelo de ameaças usado em competições de cibersegurança (por exemplo, Pwn2Own⁠(abre numa nova janela) e TyphoonPWN⁠(abre numa nova janela)). No passado, a Pwn2Own e a TyphoonPWN ofereceram recompensas de 20 000 USD e 70 000 USD, respetivamente, por exploits de elevação local de privilégios no kernel Linux. Aplicando esses valores históricos de recompensa aos 948 exploits, obtém-se uma avaliação hipotética de 18,9 a 66,3 milhões de USD, aproximadamente 16 a 55 vezes o custo do nosso pipeline.

Também testámos o nosso pipeline no programa de recompensas por vulnerabilidades kernelCTF⁠(abre numa nova janela) da Google, cujo alvo é um kernel Linux com segurança reforçada e superfícies de ataque reduzidas. Executámos o pipeline na versão mais recente do kernel Linux, no ambiente do kernelCTF, e obtivemos 25 provas de conceito de fuga de informação e 21 exploits de elevação local de privilégios. Como essa versão era incompatível com a mitigação SLAB_VIRTUAL do kernelCTF, removemo-la da configuração. Para comparação, à data da redação, o kernelCTF tinha aceitado 26 exploits de LPE de dia zero confirmados em 2026. A campanha completa durou 112 horas e custou cerca de 32 936 USD em créditos de API, sendo que a descoberta de vulnerabilidades representou 83,7% do custo da API. Se as 21 vulnerabilidades fossem aceites pelo programa, resultariam numa recompensa de cerca de 1,5 milhões de USD, aproximadamente 45 vezes o custo.

Lição principal: Com base nos valores públicos das recompensas, e com os modelos atuais com capacidades de cibersegurança, o nosso pipeline de investigação de vulnerabilidades teria gerado lucro líquido à data desta investigação. Os defensores devem analisar proativamente o seu software para tornar proibitivo o custo da sua exploração para os atacantes.

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. O nosso pipeline marcava uma vulnerabilidade como explorada quando se obtinha uma shell root. Numa execução inicial, a etapa de exploração indicou 200 exploits bem-sucedidos de elevação local de privilégios. No entanto, após revisão humana, descobrimos que 20 deles tinham obtido privilégios root através de uma vulnerabilidade de dia zero diferente da que lhes tinha sido atribuída. Isto sugere que até uma exploração bem-sucedida por agentes precisa de validação adequada.

Posteriormente, tornámos as restrições da tarefa mais rigorosas e acrescentámos uma verificação independente para confirmar que cada exploit final usava a vulnerabilidade que lhe tinha sido atribuída.

Lição principal: Na investigação autónoma de segurança, verifique o caminho seguido para chegar ao resultado, além do próprio resultado; o isolamento, a monitorização e as verificações independentes são controlos necessários.

No início desta investigação, ponderámos se deveríamos criar uma camada de orquestração complexa em torno do agente para melhorar a sua capacidade em cibersegurança. O nosso resultado sugeriu que os modelos mais capazes precisam de menos orquestração e acompanhamento. E que a melhoria marginal não justifica o custo de manutenção. Por isso, decidimos remover a camada de orquestração complexa.

A experiência comparou o GPT‑5.5 Cyber com o GPT‑5.6 Cyber. Observámos que o GPT‑5.5 Cyber não identificava de forma consistente quando e como aplicar as técnicas existentes de exploração do kernel Linux. Reunimos então 103 técnicas num formato adequado ao modelo, disponibilizámo-las no ambiente do agente e instruímo-lo a usá-las. Num conjunto de 63 potenciais vulnerabilidades a explorar, isto aumentou a taxa de sucesso de 76,2% para 88,9%.

Quando repetimos a experiência com o GPT‑5.6 Cyber, o modelo mostrou-se mais capaz de encontrar, selecionar e aplicar autonomamente as técnicas relevantes. Removemos a orquestração de técnicas e competências, e este fluxo de trabalho do GPT‑5.6 Cyber, com orquestração leve, superou o fluxo do GPT‑5.5 Cyber, que tinha uma estrutura de apoio mais complexa. Reintroduzir a camada adicional de técnicas no GPT‑5.6 Cyber proporcionou apenas uma melhoria marginal de 1,5 pontos percentuais.

Lição principal: Reavalie a orquestração e o harness à medida que as capacidades do modelo de base evoluem. Uma estrutura de apoio que melhora substancialmente uma geração de modelos pode acrescentar pouco valor a um modelo mais capaz, pelo que deve ser avaliada face ao custo de manutenção.

Inicialmente, quando lhe pedíamos diretamente propostas de correção, o modelo criava correções funcionalmente corretas que neutralizavam a prova de conceito, mas por vezes introduziam outros problemas: incluíam mais código do que o necessário, podiam prejudicar o desempenho, desviavam-se das convenções de programação ou não examinavam código relacionado à procura de variantes da mesma vulnerabilidade, o que resultava em correções incompletas.

Instruções adicionais e sucessivos ajustes ao processo de geração de correções melhoraram a sua qualidade. Isto sugere que, com a abordagem adequada, as correções de segurança geradas por IA podem ser corretas, mínimas e coerentes com as convenções do código existente. Esta é uma área de investigação ativa, e acreditamos que o processo se tornará mais fácil e eficaz com os modelos futuros. Em alguns casos, o nosso protótipo de investigação também conseguiu identificar problemas em correções escritas por especialistas humanos, que foram depois resolvidos antes da integração das correções.

Lição principal: Os modelos podem acelerar o processo de correção, mas as competências e os harnesses usados para esse fim podem precisar de ajustes iterativos para garantir que as correções cumprem de forma fiável os requisitos funcionais e não funcionais. Além disso, recomendamos usar modelos para rever, numa perspetiva adversarial, as correções geradas por humanos e por IA. Essa revisão pode identificar problemas como a possibilidade de contornar a correção, vias de ataque ou variantes não abrangidas, entre outros.

Na nossa execução no kernelCTF, além dos 21 exploits de dia zero no kernel Linux, o protótipo de investigação também encontrou e explorou uma vulnerabilidade no QEMU TCG. O agente analista recebeu a tarefa de analisar o código de entrada das chamadas de sistema e, ao escrever programas para testar transições de privilégios, deparou-se com uma falha inesperada do kernel. Fez a triagem da falha, localizou a origem do problema no 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 esta vulnerabilidade. Descobrimos esta vulnerabilidade do QEMU ao analisar manualmente os exploits e confirmámos que já tinha sido corrigida no projeto original do QEMU, mas não na versão compilada usada na experiência.

Lição principal: Os modelos de fronteira com capacidades de cibersegurança podem encontrar vulnerabilidades na infraestrutura de testes. Recomendamos testar cada componente da infraestrutura antes de realizar investigação ofensiva de vulnerabilidades. Já testámos proativamente a nossa infraestrutura, divulgando e corrigindo muitas vulnerabilidades no Kata, Moby/Docker, gVisor e noutros projetos.

O nosso objetivo é transformar a crescente capacidade dos modelos numa vantagem duradoura para quem protege a Internet. Esta investigação demonstra que a crescente capacidade dos modelos de fronteira em cibersegurança pode ser usada para procurar eficazmente vulnerabilidades em software complexo, como o kernel 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 utilizadores que deles dependem.

Através do Patch the Planet, uma iniciativa Daybreak, pretendemos alargar esta investigação a mais projetos de software críticos e desenvolver um processo fiável de aplicação automática de correções, em conjunto com responsáveis pela manutenção e parceiros de segurança. Queremos reduzir continuamente as oportunidades ao dispor dos atacantes 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 ajudar-nos a criar software que a geração seguinte tenha mais dificuldade em comprometer. Continuaremos a trabalhar para construir uma Internet segura, onde qualquer pessoa possa criar com prazer.