A empresa Anthropic anunciou a ampliação das capacidades do modelo de IA Claude Opus 4.6 para busca de vulnerabilidades no código e compartilhou os resultados de um experimento, no qual foram identificadas mais de 500 vulnerabilidades (0-day) anteriormente desconhecidas nas últimas versões de diversos projetos de código aberto. O trabalho foi focado na busca de vulnerabilidades relacionadas a problemas de gerenciamento de memória, pois é mais fácil verificar sua presença. Todas as vulnerabilidades identificadas foram classificadas como de alto nível de risco. Cada vulnerabilidade foi verificada manualmente e confirmada por funcionários da Anthropic ou pesquisadores de segurança externos contratados.
Para a análise das vulnerabilidades, foram utilizadas bases de código de populares projetos de código aberto que estão há muito tempo em teste contínuo de fuzzing no serviço OSS-Fuzz. Ao contrário do teste de fuzzing, onde é gerado um fluxo de diversas combinações aleatórias de dados de entrada, o modelo de IA tentou analisar o código, levando em consideração correções passadas para identificar erros não resolvidos semelhantes, destacando padrões problemáticos e inferindo logicamente quais dados de entrada poderiam interromper a execução.
As informações sobre as vulnerabilidades identificadas durante o experimento já começaram a ser repassadas aos mantenedores, com os quais estão sendo realizadas colaborações para a implementação de correções. Para ajudar os mantenedores durante a verificação, foram desenvolvidos manualmente patches para corrigir os problemas identificados. Como exemplo, foram citadas três vulnerabilidades no GhostScript, OpenSC e CGIF, que, no momento da publicação, foram corrigidas pelos mantenedores.
A configuração utilizada para identificar os problemas não se assemelhava aos sistemas tradicionais de busca automática de vulnerabilidades — ao modelo Claude Opus 4.6 foi concedido acesso a máquina virtual, onde além do código analisado foram instaladas ferramentas padrão para desenvolvedores (coreutils, Python, etc.) e utilitários para depuração e análise de vulnerabilidades (incluindo ferramentas para testes de fuzzing). O modelo não recebeu instruções claras sobre como usar essas ferramentas nem informações específicas sobre métodos de busca de vulnerabilidades. O modelo apenas recebeu a tarefa e teve a oportunidade de refletir sobre a melhor forma de utilizar as ferramentas disponíveis.
Na busca por vulnerabilidades no GhostScript, a IA começou tentando realizar testes de fuzzing, mas quando isso não trouxe resultados, passou a analisar o código. A análise de código também não obteve sucesso e então o modelo começou a estudar o histórico de mudanças no Git, onde notou em um dos commits uma menção à verificação de limites de buffer. Após examinar o commit, o modelo identificou que a correção adicionava uma verificação ausente dos limites de buffer ao processar fontes.
Em seguida, o modelo identificou o código que existia antes da correção e tentou encontrar no restante do código padrões semelhantes de uso da função problemática, que ainda permaneciam sem correção. Como resultado, no arquivo gdevpsfx.c foi encontrado uma chamada da função gs_type1_blend sem a verificação da validade dos valores. No final, o modelo selecionou o conteúdo de um arquivo cuja manipulação resultou em um encerramento inesperado devido à gravação de dados fora da área de memória alocada.
Na CGIF, a IA partiu do princípio de que ao descompactar arquivos GIF, a biblioteca considerava que o tamanho dos dados compactados era sempre menor que os descompactados. A busca por vulnerabilidades se concentrou em determinar as condições sob as quais os dados compactados pelo algoritmo LZW seriam maiores que os descompactados. Essas condições foram encontradas e a IA conseguiu gerar um arquivo GIT, cuja manipulação levou a um estouro de buffer. No OpenSC, o problema foi identificado após a análise do uso no código de funções potencialmente perigosas como strrchr e strcat.
Observa-se que os modelos de linguagem alcançaram um nível que permite identificar vulnerabilidades desconhecidas até então, e em breve irão superar os especialistas em segurança em termos de velocidade e escala na busca por vulnerabilidades. Espera-se que o aumento no número de vulnerabilidades identificadas exija uma reforma nos processos de divulgação, já que os 90 dias atualmente dedicados à correção serão insuficientes.
Fonte: opennet.ru
