- Em uma auditoria do ksmbd, a implementação do servidor SMB3 no kernel Linux, foi encontrada a vulnerabilidade remota de use-after-free CVE-2025-37899 usando apenas a API o3 da OpenAI, sem framework de agentes, scaffolding ou outras ferramentas
- A falha ocorre porque, durante o processamento do comando SMB
logoff, osess->userjá liberado pode continuar sendo acessado por outra thread, algo que só fica visível ao considerar conexões simultâneas e o estado de compartilhamento de sessão - Em um benchmark baseado na CVE-2025-37778, encontrada manualmente, o o3 identificou a vulnerabilidade em 8 de 100 execuções; o Claude Sonnet 3.7 conseguiu 3 vezes, e o Claude Sonnet 3.5, nenhuma
- Na condição ampliada de 12k LoC / 100k tokens de entrada, cobrindo todos os handlers de comandos SMB e o código de tratamento de conexão, a taxa de detecção da vulnerabilidade já conhecida caiu para 1 em 100, mas nesse mesmo conjunto apareceu a nova CVE-2025-37899
- Ainda há muitos falsos positivos e saídas sem utilidade, mas a probabilidade de obter uma resposta correta aumentou a ponto de valer a pena revisão e validação humana em pesquisa real de vulnerabilidades
Experimento que encontrou uma vulnerabilidade no ksmbd com o o3
- O alvo da auditoria foi o ksmbd, que implementa compartilhamento de arquivos via protocolo SMB3 no espaço de kernel do Linux
- O modelo o3 da OpenAI foi usado via
o3 API, sem scaffolding adicional, framework de agentes ou outras ferramentas - A vulnerabilidade encontrada foi a CVE-2025-37899, e a correção está no commit do kernel Linux
- O problema central é um use-after-free no handler do comando SMB
logoff, em que um objeto sem contagem de referência é liberado enquanto continua acessível por outra thread - Para encontrar essa vulnerabilidade, é preciso entender ao mesmo tempo as conexões simultâneas com o servidor e os objetos compartilhados em certas situações
- A avaliação inclui a observação de que este parece ser o primeiro caso publicamente discutido em que um LLM encontrou uma vulnerabilidade com essas características
Vulnerabilidade de referência CVE-2025-37778
- Primeiro, a CVE-2025-37778, encontrada manualmente, foi usada como benchmark para avaliar o desempenho do o3
- Essa vulnerabilidade é um use-after-free que ocorre ao processar a requisição
session setupde um cliente remoto no caminho de autenticação Kerberos krb5_authenticateliberasess->userquandosess->state == SMB2_SESSION_VALID- Em seguida, o código depende da suposição de que
ksmbd_krb5_authenticatevai reinicializar com um novo valor válido ou, após retornar-EINVAL, quesess->usernão será mais usado - Na prática, é possível fazer com que
ksmbd_krb5_authenticatenão reinicializesess->user, esess->userainda pode ser acessado mesmo quandokrb5_authenticateretorna-EINVAL
Configuração do benchmark e prompt
- A CVE-2025-37778 foi usada como benchmark porque fica na superfície de ataque remota e exige avaliar ao mesmo tempo a condição
sess->state == SMB2_SESSION_VALID, o caminho sem reinicialização e o caminho de acesso após a liberação - O código mínimo necessário para explicar o caminho da vulnerabilidade foi calculado em cerca de 3.3k LoC
- A entrada do experimento incluiu o handler do comando
session setupe as funções chamadas por ele até profundidade de chamada 3 - Também foram incluídos o recebimento de pacotes, o parsing da requisição, a seleção do handler do comando e o código de limpeza da conexão após a conclusão do handler, reduzindo suposições sobre como as estruturas de dados são inicializadas
- A entrada final tinha cerca de 3.3k LoC / 27k tokens, e o arquivo analisado foi publicado como session_setup_code.prompt
- O prompt incluía as seguintes condições
- Instrução para procurar vulnerabilidades de use-after-free
- Contexto de alto nível sobre o papel, a arquitetura e o modelo de ameaça do ksmbd
- Forte orientação para preferir não reportar a reportar falso positivo
- O arquivo completo do prompt está no repositório o3_finds_cve-2025-37899
- A execução usou a ferramenta
llmde Simon Willison
Resultados do benchmark da CVE-2025-37778
- O harness do experimento executou a mesma consulta 100 vezes e salvou os resultados
- O o3 encontrou a CVE-2025-37778 em 8 de 100 execuções
- Em 66 de 100 casos, concluiu que não havia bug, gerando falso negativo
- Os 28 restantes foram falsos positivos
- O resultado comparativo foi o seguinte
- Claude Sonnet 3.7: 3 descobertas em 100 execuções
- Claude Sonnet 3.5: 0 descobertas em 100 execuções
- Nesse benchmark, o o3 mostrou um resultado 2 a 3 vezes melhor que o Claude Sonnet 3.7
- Relatórios de exemplo foram publicados como resultado do o3 e resultado do Sonnet 3.7
- A saída do o3, pela estrutura e foco, se parece com um relatório de bug resumido escrito por humano, embora às vezes curta demais e menos clara
- A saída do Sonnet 3.7 apareceu mais próxima de um fluxo de raciocínio ou log de trabalho
Experimento ampliado para todos os handlers de comando
- No experimento seguinte, foi fornecido ao o3 não só o handler de
session setup, mas o código de todos os handlers de comandos SMB - Os handlers estão em
smb2pdu.c, e o arquivo tem cerca de 9k LoC - Somando todos os handlers, o código de configuração e limpeza de conexão e a rotina de dispatch dos handlers, o total ficou em cerca de 12k LoC / 100k tokens de entrada
- Nessa condição, o experimento também foi executado 100 vezes
- O o3 encontrou a vulnerabilidade já conhecida de autenticação Kerberos CVE-2025-37778 apenas 1 vez em 100, mostrando degradação clara de desempenho com o aumento do número de tokens de entrada
- No mesmo conjunto de resultados, apareceu um relatório da nova vulnerabilidade até então desconhecida, a CVE-2025-37899
Caminho vulnerável da CVE-2025-37899
- A nova vulnerabilidade também está relacionada à liberação de
sess->user, mas desta vez ocorre no handler de session logoff smb2_session_logofffunciona na seguinte ordem- Chama
ksmbd_close_session_fds(work) - Chama
ksmbd_conn_wait_idle(conn) - Define o estado da sessão como
SMB2_SESSION_EXPIRED - Se
sess->userexistir, libera comksmbd_free_user(sess->user)e definesess->user = NULL
- Chama
- O cenário de vulnerabilidade descrito no relatório do o3 é o seguinte
- Em SMB 3.0 ou superior, o segundo transporte é vinculado a uma sessão existente e
conn->binding == true - A Worker-A processa uma requisição comum, como WRITE, em outra conexão C2
smb2_check_user_session()salva emwork->sesso ponteiro existente parastruct ksmbd_sessione incrementa a contagem de referência da sessão, mas não mantém uma referência separada parasess->user- A Worker-B processa um SMB2 LOGOFF da mesma sessão na primeira conexão C1 e executa
smb2_session_logoff() ksmbd_conn_wait_idle(conn)espera apenas as requisições em execução naquela conexão, não as requisições de outras conexões que usam a mesma sessão- A Worker-A continua executando e pode fazer acessos como
user_guest(sess->user),ksmbd_compare_user(sess->user, …)esess->user->uid
- Em SMB 3.0 ou superior, o segundo transporte é vinculado a uma sessão existente e
- Dependendo do timing, isso pode virar um use-after-free apontando para um objeto slab já liberado ou, se a leitura acontecer após
sess->user = NULL, um NULL dereference com potencial de DoS
Correção incorreta e o valor dos resultados do o3
- A primeira correção proposta para a CVE-2025-37778 consistia em adicionar
sess->user = NULLapósksmbd_free_user(sess->user) - Depois de ler o relatório da CVE-2025-37899, ficou claro que essa correção era insuficiente
- O handler de
logoffjá fazsess->user = NULL, mas ainda assim permanece vulnerável, porque o protocolo SMB permite vincular duas conexões diferentes à mesma sessão - No caminho de autenticação Kerberos, outra thread também pode acessar
sess->userna curta janela entre a liberação e a atribuição de NULL - Alguns relatórios do o3 cometeram o mesmo erro, mas outros conseguiram perceber que, por causa da possibilidade de session binding, apenas
sess->user = NULLnão basta - Uma limitação é que, pela alta proporção de true positives em relação a false positives, não é certo que todos os relatórios tenham sido revisados com o cuidado necessário
Posição prática na pesquisa de vulnerabilidades
- Em criatividade, flexibilidade e generalidade, LLMs estão mais próximos de auditores humanos de código do que de técnicas tradicionais de análise de programas
- Como comparação, são citados symbolic execution, abstract interpretation e fuzzing
- Desde o GPT-4 já existia a possibilidade de usar LLMs em pesquisa de vulnerabilidades, mas os resultados em problemas reais ainda ficavam abaixo do esperado
- O o3 funciona de forma suficientemente útil em raciocínio sobre código, perguntas e respostas, programação e resolução de problemas para elevar o desempenho de pesquisadores reais de vulnerabilidades
- Ainda está longe de ser perfeito e pode gerar resultados sem sentido que frustram o usuário
- O que mudou é a avaliação de que, pela primeira vez, a probabilidade de obter uma resposta correta ficou alta o bastante para justificar aplicar isso a problemas reais
1 comentários
Comentários do Hacker News
É um detalhe pequeno, mas a forma como o autor organiza o projeto parece útil. Ele cria arquivos
.promptseparados para o prompt do sistema, informações de contexto e instruções auxiliares [1], e os executa comllmIsso mostra que um bom uso de LLMs, assim como outras ferramentas de engenharia, exige um pensamento de engenharia sistemático, centrado em especificações cuidadosas e que equilibra bem as restrições de projeto
[1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899
Tudo parece encantamento baseado em intuição. Frases como “você é um especialista em encontrar vulnerabilidades”, “relate apenas vulnerabilidades reais, sem falsos positivos”, ou formas de organizar com tags HTML falsas porque o modelo parece gostar disso. Não vejo onde está a engenharia aqui
Esses prompts deveriam ser chamados de dicas, não de instruções. Todos os LLMs atuais ignoram o prompt quando ele entra em conflito com seu único objetivo superior: produzir uma resposta, seja ela verdadeira ou não
Pedir a um LLM para ajudar a escrever prompts também é surpreendentemente eficaz. Todos os meus fragmentos de prompt também foram projetados com ajuda de LLMs
Pessoalmente, deixo tudo em arquivos org-mode e copio e colo em conversas do ChatGPT quando preciso. Prefiro interações mais “em forma de debate”, mas a abordagem é a mesma
O texto diz que a relação sinal-ruído é de cerca de 1:50. O autor conhece muito bem essa base de código, então está numa boa posição para separar o sinal do ruído
O avanço real virá de automatizar essa parte, então pretendo continuar acompanhando
Sempre que surge um novo LLM de fronteira, excetuando modelos que usam a entrada como dados de treinamento, rodo esses exercícios de entrevista. Fiquei surpreso ao ver que a taxa de respostas que funcionam na primeira tentativa continua consistentemente em torno de 1:10, e muitas vezes é preciso cutucar por mais de 10 rodadas para o modelo encontrar o próprio erro
Por isso, essa relação sinal-ruído em um tema mais obscuro me parece plausível
Os resultados variaram bastante, e vou divulgar tudo em uma apresentação de conferência em breve, então podem ficar animados. Isso deve mostrar bem o estado atual da área
Edit: a formulação estava confusa
Um LLM desses talvez fosse uma versão sintética de alguém que trabalhou por anos na base de código e aprendeu todo tipo de particularidade
Dá para colocar muita coisa em contexto longo, mas algumas bases de código já têm 200 mil tokens só de código, então não sei
Isso vale especialmente em um esquema de torneio binário, como o RAInk que apareceu aqui algumas semanas atrás, e também há formas de usar consenso entre LLMs diferentes. Fiquei surpreso por não usarem o Gemini 2.5 PRO aqui; pela minha experiência, ele é o LLM mais forte para esse tipo de tarefa
A parte mais interessante e importante deste texto foi que o autor rodou a busca por vulnerabilidades 100 vezes para cada modelo
É muito mais computação do que eu pretendia usar na maioria dos problemas que tentei resolver com modelos de linguagem grandes, mas talvez seja o caso de simplesmente continuar rodando o modelo
Não sei como será o mundo da cibersegurança quando o custo de inferência chegar perto de zero, mas será um espaço muito diferente do atual
Acaba ficando mais próximo de celebrar luxo e desperdício. Mesmo diante da mudança climática global, continuamos queimando recursos em coisas triviais como se estivéssemos nos anos 1950
Ou ele teve muita sorte, ou, como eu suspeitava, o Gemini 2.5 PRO parece encontrar essa vulnerabilidade com mais facilidade. A taxa de sucesso foi alta, então bastou rodar algumas vezes o prompt a seguir: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...
Recentemente, esse padrão vem se repetindo
Quando há um problema com uma definição clara e uma função de avaliação, faz-se com que o LLM reduza o espaço de soluções. LLMs são muito fortes em reconstrução de padrões e podem funcionar bem se a resposta seguir um padrão parecido com algo já conhecido
Neste caso, o problema é um tipo específico de vulnerabilidade de segurança, e o avaliador é um especialista. A escala é diferente, mas, em espírito, isso se parece com tentativas recentes de usar LLMs em otimização genética
“Mathematical discoveries from program search with large language models” também é uma leitura interessante, e lembro que já apareceu no HN algum tempo atrás
https://www.nature.com/articles/s41586-023-06924-6
Ainda assim, pessoalmente acho um pouco forçado concluir, com base apenas nesse experimento, que LLMs raciocinam sobre código
Espero que isso seja real, e que não seja a mesma coisa que continua acontecendo com o curl
[1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...
Não tenho certeza sobre a alegação de que esta é a primeira vulnerabilidade descoberta por LLM. Por exemplo, o OSS-Fuzz [0] encontrou algumas por fuzzing, e o Big Sleep também encontrou usando uma abordagem com agentes [1]
[0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
[1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...
O que eu disse no texto foi: “Para entender a vulnerabilidade, é preciso raciocinar sobre conexões simultâneas ao servidor e sobre como vários objetos são compartilhados em determinadas situações. O o3 entendeu isso e encontrou o ponto em que um objeto específico, que não tinha contagem de referências, era liberado enquanto ainda permanecia acessível por outra thread. Até onde sei, esta é a primeira discussão pública sobre um LLM encontrar uma vulnerabilidade dessa natureza”
O que eu queria dizer é que, até onde sei, esta é a primeira documentação pública de um LLM encontrando esse tipo de bug: um bug originado de uma quantidade não trivial de código e de acesso simultâneo a recursos compartilhados. Pelo menos para mim, é um marco interessante no avanço dos LLMs
Considerando o valor de descobrir zero-days, se fosse possível encontrá-los de forma confiável com apenas algumas centenas de chamadas de API, praticamente todas as agências de inteligência do mundo despejariam dinheiro nisso
Ainda mais se fosse possível ajustar finamente o modelo com muitos exemplos, e não acho que lugares como a OpenAI fariam esse tipo de coisa via API pública
Para agências governamentais ou outras organizações, obviamente essas restrições não são um problema. Elas se aplicam apenas a todos os demais. Por isso, as pessoas acabarão usando outros modelos e agentes sem essas limitações
É seguro presumir que há muitas vulnerabilidades espalhadas por softwares importantes. Agora conseguimos encontrá-las. Vai começar uma situação em que a teoria dos jogos de corrida armamentista se aplica à segurança de computadores e ao hacking. Provavelmente isso chegará antes do que se espera
Sei que alguns desenvolvedores do kernel “validaram” esse bug, mas fico curioso se alguém de fato criou e testou uma prova de conceito
É uma parte tão central do processo, mas a prova de conceito está completamente ausente. Sem uma prova de conceito, não dá para saber que problemas podem aparecer no meio do caminho e, portanto, não dá para julgar a explorabilidade ou o impacto. Pelo menos o autor não chamou isso de execução remota de código sem validação
Mas e se houver uma peça do quebra-cabeça que o autor e os desenvolvedores deixaram passar, ou que presumiram que o o3 tivesse tratado, mas que na verdade estava fora do contexto do o3, e isso invalidar a vulnerabilidade em si?
Não estou dizendo que exista algo assim, nem que eu vá gastar tempo fazendo o trabalho do autor por ele. Só que este relatório não está totalmente validado e, considerando que pode se tornar um post influente na área de pesquisa de vulnerabilidades com LLMs, isso me parece um precedente perigoso
Pessoalmente, acho que deveríamos aplicar PoC || GTFO com mais rigor do que nunca a qualquer relatório de vulnerabilidade gerado por modelo
A visão de que o o3 é muito melhor que modelos anteriores ou outros modelos atuais continua válida, e a metodologia também é interessante. Entendo o desejo e a necessidade de escrever dessa forma para fazer as pessoas prestarem atenção em algo específico. Esse é o problema do clickbait. Mas, por favor, precisamos fazer melhor. É preciso criar uma prova de conceito e verificar as afirmações, não ser preguiçoso. Se você está escrevendo um post que pode influenciar a forma como pesquisadores de vulnerabilidades conduzem suas pesquisas, deve incentivar validação, não suposições teóricas. Caso contrário, em vez de aprofundar o entendimento dos sistemas com relatórios verificáveis e comprovados, relatos falsos porém plausíveis acabarão espalhando ignorância
Há um pequeno trecho maravilhoso que captura perfeitamente como costuma ser a maioria das minhas sessões de desenvolvimento de prompts