- Compartilha a experiência de usar o modelo OpenAI o3 para descobrir uma vulnerabilidade remota 0-day (CVE-2025-37899) na implementação SMB do kernel Linux
- Durante o processo de benchmarking da capacidade de análise de LLMs sobre o código do ksmbd, foram feitos experimentos comparando o desempenho do LLM com base em uma vulnerabilidade já encontrada manualmente
- No processo de detecção da vulnerabilidade, foi estruturado um contexto por função e fornecido um prompt adequado para que o o3 pudesse reconhecer a falha
- Como resultado do experimento, o o3 encontrou vulnerabilidades com precisão 2 a 3 vezes maior do que LLMs anteriores e também descobriu automaticamente um novo tipo de bug use-after-free
- LLMs, especialmente modelos mais recentes como o o3, demonstram flexibilidade e criatividade semelhantes à abordagem humana em auditoria de código e pesquisa de vulnerabilidades, aumentando seu valor de uso prático
Introdução
Este texto apresenta como foi descoberta uma vulnerabilidade remota 0-day na implementação SMB do kernel Linux (ksmbd) usando o modelo o3 da OpenAI. O experimento foi conduzido utilizando apenas a API do o3, sem frameworks ou ferramentas adicionais. O ksmbd é o servidor que implementa o protocolo SMB3 dentro do kernel Linux, responsável pelo compartilhamento de arquivos em rede. A auditoria de vulnerabilidades começou como uma pausa no trabalho com desenvolvimento relacionado a LLMs, e acabou servindo como benchmark para medir quão bem o o3 consegue encontrar bugs reais. Aqui, o foco está especialmente na vulnerabilidade zero-day CVE-2025-37899 encontrada pelo o3.
Essa vulnerabilidade é um problema de use-after-free que ocorre no processamento do comando SMB logoff. Ela exige compreender situações de conexões simultâneas com o servidor e a forma como múltiplas threads compartilham determinados objetos. O o3 detectou a vulnerabilidade ao entender, dentro do contexto, esses problemas de concorrência e erros no gerenciamento de objetos. Este é o primeiro caso público em que um LLM encontrou esse tipo de vulnerabilidade.
A principal mensagem é que o o3 mostra um salto importante nas capacidades de análise de código e raciocínio lógico dos LLMs, e que pesquisadores de vulnerabilidades precisam acompanhar esse movimento. Embora LLMs não substituam especialistas, o texto sugere que eles já evoluíram para se tornar uma ferramenta capaz de elevar drasticamente a produtividade e a eficiência de especialistas. Em bases de código com menos de 10 mil linhas, o o3 pode oferecer ajuda prática para detectar e resolver a maior parte dos problemas.
Benchmark do o3 com CVE-2025-37778
Contexto e objetivo do benchmark
Primeiro, a capacidade do o3 de detectar vulnerabilidades foi avaliada usando como referência a CVE-2025-37778, uma vulnerabilidade encontrada manualmente antes (doravante, a vulnerabilidade de autenticação Kerberos). Trata-se de um problema em que ocorre use-after-free durante o processo de autenticação do cliente quando o estado da sessão satisfaz certas condições.
- Quando o estado da sessão é
SMB2_SESSION_VALID, o objeto de usuário é liberado da memória - Se a autenticação falha depois disso, o objeto de usuário não é reinicializado, e passa a ser acessível nesse estado, provocando use-after-free
- Para entender todo o caminho relacionado, é preciso seguir cerca de 3.300 linhas de código, o que faz disso uma tarefa de benchmark com dificuldade apropriada
Construção do contexto de análise
No experimento, o contexto (trechos de código) fornecido ao LLM foi montado com cuidado do ponto de vista de um sistema real de detecção automatizada de vulnerabilidades. Por unidade de handler de comando SMB, foram incluídas funções principais e subfunções até 3 níveis de profundidade de chamada, de modo a fornecer todo o código logicamente relacionado (total de 3,3 mil LoC, cerca de 27 mil tokens). Para obter resultados confiáveis, também foi necessário incluir funções relacionadas a parsing de dados, bifurcação de requisições e encerramento de conexão.
Os prompts e materiais de entrada usados podem ser conferidos no repositório relacionado no Github. As seguintes condições foram dadas ao LLM:
- instrução explícita para detectar vulnerabilidades de use-after-free
- breve explicação da estrutura básica do ksmbd e do modelo de ameaça
- uso de prompts orientados a evitar falsos positivos (False Positive)
As consultas reais foram executadas repetidamente com a ferramenta de linha de comando llm para coletar os resultados do experimento (N=100).
Resultados do benchmark
- o3: detectou a vulnerabilidade de autenticação Kerberos 8 vezes em 100, deixou de detectá-la 66 vezes e relatou 28 falsos positivos
- Claude Sonnet 3.7: detectou apenas 3 vezes
- Claude Sonnet 3.5: falhou em detectar em todas as 100 execuções
No fim, o o3 registrou uma precisão 2 a 3 vezes maior do que os LLMs anteriores. Além disso, a saída do o3 foi concisa, parecendo um relatório-resumo escrito por um pesquisador de segurança humano. Já o resultado do Sonnet 3.7 deu uma impressão mais próxima de um log de trabalho centrado no processo, com vantagens e desvantagens ao mesmo tempo.
Descoberta de um 0-day real (CVE-2025-37899) com o o3
Experimento em ambiente com grande volume de código de entrada
Além da vulnerabilidade Kerberos, também foi tentada a detecção geral de vulnerabilidades com o o3 incluindo todos os handlers de comandos SMB (cerca de 9 mil linhas). Somando vários handlers, código de conexão/desconexão e outros trechos, cerca de 12 mil LoC (aproximadamente 100 mil tokens) foram fornecidos de uma só vez. Em 100 execuções repetidas, a vulnerabilidade de autenticação Kerberos foi detectada apenas uma vez, deixando clara a queda de desempenho, mas o objetivo principal era experimentar a utilidade do LLM em um escopo maior de código.
A nova vulnerabilidade encontrada neste experimento
Nesse processo, o o3 encontrou um novo bug de use-after-free além do caso de autenticação Kerberos. Trata-se de um problema de concorrência no handler de logoff da sessão: em um cenário de conexões simultâneas, duas threads compartilham/acessam o objeto user da sessão, e após uma thread liberar o objeto, a outra pode continuar referenciando-o.
Resumo do relatório automático de vulnerabilidade do o3
- Duas threads de trabalho cooperam de forma que uma, ao executar o encerramento da sessão (
logoff), libera da memória o objetouser, enquanto a outra continua usando esse objeto na sessão existente - Se ocorrer um dereference por outro caminho logo após a liberação (antes de o ponteiro ser inicializado como
NULL), surge um use-after-free clássico - Dependendo do timing, também pode ocorrer DoS por
NULLdereference - Isso pode levar a corrupção de memória no kernel e execução arbitrária de código
Insights obtidos a partir do relatório automático
A partir desse relatório automático, ficou claro que a forma de correção usada na vulnerabilidade anterior de autenticação Kerberos (definir como NULL logo após a liberação) não é uma solução fundamental para o tratamento de logoff. Em outras palavras, só é possível garantir segurança considerando o binding da sessão e os vetores de ataque entre threads. O próprio o3, em alguns relatórios, percebeu esse ponto e demonstrou ser capaz de sugerir uma correção “mais forte”.
Conclusão
LLMs, especialmente modelos recentes como o o3, mostram desempenho muito mais próximo ao de pesquisadores humanos de segurança em análise criativa e flexível de código do que as técnicas anteriores. Até recentemente isso era tratado como uma possibilidade teórica, mas o o3 é o primeiro caso em que, em exemplos reais, o nível alcançou algo realisticamente “útil”. Claro, o o3 ainda está sujeito a falsos positivos e omissões, mas a probabilidade de produzir resultados realmente úteis aumentou a ponto de fazer sentido seu uso prático. Este é o momento em que pesquisadores de vulnerabilidades e desenvolvedores precisam descobrir como integrar LLMs de forma eficiente aos seus fluxos de trabalho.
1 comentários
Opiniões no Hacker News
O autor explicou que organiza o projeto criando separadamente arquivos
.promptpara prompt de sistema, contexto, comandos auxiliares etc., e os executa viallmIsso passa a sensação de que usar LLMs de forma tão estruturada exige um pensamento de projeto cuidadoso e um ajuste fino de especificações, quase como qualquer outra ferramenta de engenharia
O projeto relacionado pode ser visto aqui
Curiosamente, achei engraçado que o autor tenha admitido com sinceridade sobre essa parte que “na verdade, todo o meu prompt de sistema é baseado em suposições e está longe de ser ciência ou engenharia”
Existem várias formas de escrever prompts, mas não há um critério claro para avaliá-las ou compará-las, então isso parece quase como entoar feitiços improvisados
Por exemplo, instruções como “você é um especialista em encontrar vulnerabilidades”, “me mostre apenas vulnerabilidades reais, não falsas”, ou separar coisas com tags HTML arbitrárias que supostamente fazem o modelo responder melhor
Fico me perguntando onde exatamente entra a parte de engenharia nisso
Acho engraçado trazer princípios de engenharia para tentar controlar um sistema que é inerentemente instável e imprevisível
Talvez o nome mais apropriado para esses prompts seja “dicas”
Hoje em dia, quase todos os LLMs frequentemente ignoram o prompt sob o objetivo intrínseco de sempre fornecer uma resposta, seja ela verdadeira ou não, mesmo quando o prompt é contraditório
No post foi mencionado que a relação sinal-ruído era de cerca de 1:50, e acho que o autor conseguiu selecionar bem os sinais relevantes porque conhece bem a base de código
Vejo justamente essa parte, a automação da identificação de sinais relevantes, como o grande potencial de usar LLMs de verdade, então pretendo acompanhar de perto os próximos desdobramentos
Estamos desenvolvendo um sistema para melhorar esse problema da relação sinal-ruído e também estamos fazendo benchmark direto com agentes de software populares recentemente
A variação nos resultados é muito grande, e pretendemos divulgar todos os experimentos em uma conferência em breve
Deve dar para ter uma boa visão do estado da arte do setor
Pensei nisso há alguns dias: será que não daria para aproveitar todo o histórico do kernel Linux, como todas as mudanças no git e mailing lists, para evoluir um modelo fine-tuned?
Um LLM assim talvez pudesse se tornar uma versão sintética mais próxima da intuição de desenvolvedores que realmente lidaram com esse código por muito tempo
Só com alto contexto já dá para cobrir bastante coisa, e algumas codebases passam de 200 mil tokens só no código, então acho que existe potencial
Uma taxa de 1:50 é excelente em uma situação tipo “procurar agulha no palheiro”
Se o LLM também escrevesse sozinho o harness e os testes de prova de conceito para comprovar cada suspeita de vulnerabilidade, a relação sinal-ruído provavelmente melhoraria muito
Mas hoje esse tipo de automação ainda é caro demais, o que é uma pena
O que mais me impressionou foi o fato de o próprio autor ter repetido a busca por vulnerabilidades 100 vezes para vários modelos de LLM
Esse nível de investimento de recursos é muito alto em comparação com a maioria dos problemas em que já usei LLMs, e agora fiquei pensando se não devo também deixar o modelo fazer uma “repetição burra” dessas
No fim das contas, a conclusão é que isso exige muito dinheiro
Vulnerabilidades zero-day podem ser vendidas por valores altos, e também dá para ganhar dinheiro com bug bounty
Comparado com essas recompensas, o custo de usar LLMs é muito pequeno
Um cenário futuro de segurança em que o custo de inferência se aproxime de zero deve ser completamente diferente
Rodar 100 vezes por modelo também significa um consumo de energia considerável
Quando encontrar uma vulnerabilidade comum em código C passa a exigir esse nível de recursos, isso esvazia um pouco o significado da descoberta e destaca mais o desperdício e o luxo
Considerando a crise climática global atual, não consigo deixar de me preocupar ao ver recursos sendo queimados em coisas sem tanto valor, como nos anos 1950
Acho que, como o Claude não recebeu um scratchpad separado, o fluxo de raciocínio e o relatório acabaram se misturando no resultado
Eu gostaria de experimentar o quanto o Claude mudaria se tivesse oficialmente um espaço permitido para organizar o pensamento
O o3 entrega a essência de forma mais refinada, quase como um bug report escrito por humano, enquanto o resultado do Sonnet 3.7 parece ainda manter traços do fluxo mental ou do log de trabalho, no mesmo sentido
Já usei diretamente o o3, o 3.7 e o Gemini 2.5 Pro, e minha impressão é que o o3 está em outro nível
As pontuações de benchmark talvez não pareçam tão diferentes assim, mas em tarefas complexas o significado dessa diferença cresce bastante
Fico curioso por que foi anunciado em novembro do ano passado e só lançado há cerca de um mês (talvez por questões de segurança), e já estou esperando o o4
Queria saber se alguém pode recomendar casos de uso, artigos ou links relacionados ao uso de “scratchpad” em pesquisa
Gostei de como isso resume bem a essência do processo de prompt engineering
Especialmente a parte de “fiz o melhor que pude para orientar o modelo de modo que vulnerabilidades incorretas não fossem marcadas como falsos positivos, mas não tenho como saber se isso realmente ajuda, apenas espero que ajude; ainda não consegui avaliar suficientemente se isso funciona, então não é nem ciência nem engenharia; vou compartilhar a avaliação depois”, porque isso se parece demais com o meu próprio fluxo de desenvolvimento de prompts
Acho que esse talvez seja o caso de uso mais adequado para LLMs: essa área de detecção automática de vulnerabilidades
Em teoria, daria para automatizar o processo inteiro e tratar o LLM como um fuzzer muito avançado, mantendo o alvo rodando continuamente em uma VM e detectando possíveis vulnerabilidades reais quando surgirem comportamentos anômalos
(Lembrando que muitos exploits iniciais acabam primeiro derrubando a máquina ou causando crash antes de serem refinados)
Esse uso de LLMs parece muito eficaz por um lado, mas por outro também sugere que “o fato de podermos fazer esse tipo de teste não quer dizer que algo tremendamente novo ou decisivo tenha sido revelado”
Compartilho uma apresentação minha sobre automação de targeting de bugs em zk (provas de conhecimento zero) link no YouTube
Os parâmetros extras servem basicamente para rastreamento do link
Espero sinceramente que isso não vire uma sequência interminável de problemas como acontece com o curl
Para contexto relacionado, veja o texto de Daniel Stenberg
Pelo que sei, o ksmbd é conhecido como um servidor SMB em espaço de kernel, mais leve e voltado a alto desempenho do que o servidor Samba tradicional
Q1: quem de fato usa ksmbd em produção?
Q2: por que usa?
Alguém sabe se isso suporta ACL de forma nativa, como no Windows?
(Essa era a última razão para continuar usando Solaris, e entendo que isso é suportado via ZFS)
O Samba ainda está preso a estruturas anacrônicas, como sincronizar UID/GID e o modelo de segurança do Unix
Servidores SMB em kernel também já tiveram vulnerabilidades remotas graves de root no Windows, então é preciso deixar claro esse trade-off
A razão é problema de licença
O Samba é GPLv3, enquanto o Linux só pode usar GPLv2
Suponho que usem simplesmente por ser leve e de alto desempenho
Acho que é um motivo parecido com usar
kmod-trelayem vez derelaydAcho que o maior desafio de curto prazo dos LLMs, em termos de Alignment Problem, aparece justamente nesse tipo de automação de vulnerabilidades
Recentemente encontrei, com quase nenhum esforço e usando LLM, uma falha de segurança realmente séria em um servidor de nicho que eu uso às vezes
Se esse mercado for automatizado, fico preocupado com a possibilidade de surgirem em massa problemas graves em todo tipo de software de cauda longa que antes não valia o esforço manual para atacar
Por outro lado, graças a esse avanço tecnológico, nós também passamos a poder analisar nossa própria base de código de forma automatizada sob uma “perspectiva adversária”
Isso nos dá a chance de corrigir preventivamente vulnerabilidades que, de outra forma, seriam encontradas por pesquisadores e depois exploradas
Por isso, não acho adequado chamar isso de problema de alignment
Atacantes podem automatizar a descoberta de vulnerabilidades, mas defensores também podem ter essa capacidade
Também é possível configurar automação defensiva no processo de aprovação de commits ou a cada build