Os pesquisadores de segurança holandesos e iranianos criaram uma ferramenta Genai automatizada que pode digitalizar enormes repositórios de código aberto e um código vulnerável que pode comprometer os aplicativos.
Testado pela varredura do GitHub para um determinado caminho que a vulnerabilidade de travessia em projetos Node.js existe desde 2010, a ferramenta identificou 1.756 projetos vulneráveis, alguns descritos como “muito influentes” e levaram a 63 projetos que foram corrigidos até agora.
A ferramenta abre a possibilidade de plataformas Genai, como o ChatGPT, criar e distribuir automaticamente patches nos repositórios de código, aumentando drasticamente a segurança dos aplicativos de código aberto.
Mas a pesquisa, descrita em um artigo publicado recentementetambém aponta para uma séria limitação no uso da IA que precisará ser corrigida para que esta solução seja eficaz. Embora o patch automatizado por um grande modelo de linguagem (LLM) melhora drasticamente a escalabilidade, o patch também pode introduzir outros bugs.
E pode ser difícil erradicar completamente a vulnerabilidade específica em que trabalharam porque, após 15 anos de exposição, alguns modelos populares de grandes idiomas (LLMS) parecem ter sido envenenados com isso.
Por que? Porque os LLMs são treinados em bases de código de código aberto, onde esse bug é enterrado.
De fato, os pesquisadores descobriram que, se um LLM estiver contaminado com um padrão de código -fonte vulnerável, ele gerará esse código mesmo quando instruído a sintetizar o código seguro. Portanto, dizem os pesquisadores, uma lição é que os padrões populares de código vulneráveis precisam ser erradicados não apenas de projetos de código aberto e recursos dos desenvolvedores, mas também do LLMS, “o que pode ser uma tarefa muito desafiadora”.
Hackers estão plantando código ruim há anos
Os atores de ameaças foram Plantando vulnerabilidades em repositórios de código aberto Durante anos, esperando que, antes que os bugs sejam descobertos, eles possam ser usados para se infiltrar nas organizações que adotam aplicativos de código aberto. O problema: os desenvolvedores, sem saber, copiarem e colam código vulnerável de plataformas de compartilhamento de código, como o Stack Overflow, que entra em projetos do GitHub.
Os atacantes precisam conhecer apenas um padrão de código vulnerável para poder atacar com sucesso muitos projetos e suas dependências a jusante, observam os pesquisadores.
A solução criada pelos pesquisadores pode permitir a descoberta e a eliminação de orifícios de código aberto em escala, não apenas em um projeto de cada vez, como é o caso agora.
No entanto, a ferramenta não é “digitalizada para isso uma vez, corrija tudo”, porque os desenvolvedores geralmente gargalham repositórios sem contribuir para os projetos originais. Isso significa que a vulnerabilidade seja verdadeiramente apagada, todos os repositórios com uma peça vulnerável de um código teriam que ser digitalizados e corrigidos.
Além disso, o padrão de código vulnerável estudado nesta pesquisa usou o nome do caminho diretamente do URL, sem formatação especial, criando uma falha fácil de explorar. Esse é o padrão em que a ferramenta se concentra; Outros canais do código ruim não são detectados.
Os pesquisadores lançarão a ferramenta em agosto em uma conferência de segurança no Vietnã. Eles planejam melhorar e estendê -lo em várias direções, principalmente integrando outros padrões de código vulneráveis e melhorando a geração de patches.
Especialista cético
No entanto, Robert Beggs, chefe da empresa de resposta a incidentes canadenses Digitaldefence, é cético em relação ao valor da ferramenta em seu estado atual.
A idéia de uma ferramenta automatizada para digitalizar e corrigir códigos maliciosos já existe há algum tempo, ele apontou, e ele credita os autores por tentar abordar muitos dos possíveis problemas já levantados.
Mas, acrescentou, a pesquisa ainda não lida com perguntas como quem é responsável se um patch defeituoso prejudicar um projeto público e se um gerente de repositório pode reconhecer que uma ferramenta de IA está tentando inserir o que pode ser uma vulnerabilidade em um aplicativo?
Quando foi sugerido que a gerência teria que aprovar o uso de uma ferramenta assim, Beggs se perguntou como os gerentes saberiam que a ferramenta é confiável e – novamente – quem seria responsável se o patch fosse ruim?
Também não está claro quanto, se houver, testar pós-remediação, a ferramenta fará para garantir que o patch não causasse mais danos. O artigo diz que, em última análise, a responsabilidade de garantir que o patch esteja correto está com os mantenedores do projeto. A parte da IA da ferramenta cria um patch, calcula uma pontuação CVSS e envia um relatório aos mantenedores do projeto.
Os pesquisadores “têm um excelente processo e eu lhes dou crédito whole por uma ferramenta que tem muita capacidade. No entanto, eu pessoalmente não tocaria a ferramenta porque lida com a alteração do código -fonte”, disse Beggs, acrescentando: “Não sinto que a inteligência synthetic esteja no nível para permitir que ele gerencie o código -fonte para um grande número de aplicações”.
No entanto, ele admitiu, os trabalhos acadêmicos geralmente são apenas o primeiro passe em um problema.
Os desenvolvedores de código aberto podem fazer parte do problema
Ao longo do caminho, os pesquisadores também descobriram um fato perturbador: os desenvolvedores de aplicativos de código aberto às vezes ignoram os avisos de que certos trechos de código são radioativos.
O código vulnerável que os pesquisadores desejavam consertar o maior número possível de projetos do GitHub, datado de 2010, e é encontrado no Github Gist, um serviço para compartilhar trechos de código. O código cria um servidor de arquivos HTTP estático para aplicativos da Internet Node.js. “(No entanto), apesar de sua simplicidade e popularidade, muitos desenvolvedores parecem saber que esse padrão de código é vulnerável ao ataque de travessia do caminho”, escrevem os pesquisadores.
Mesmo aqueles que reconheceram o problema enfrentaram discordâncias de outros desenvolvedores, que esmagaram repetidamente a noção de que o código period ruim. Em 2012, um desenvolvedor comentou que o código estava vulnerável. Dois anos depois, outro desenvolvedor levantou a mesma preocupação com a vulnerabilidade, mas outro desenvolvedor disse que o código period seguro, depois de testá -lo. Em 2018, alguém comentou novamente sobre a vulnerabilidade, e outro desenvolvedor insistiu que essa pessoa não entendeu o problema e que o código estava seguro.
Separadamente, o snippet de código foi visto em uma cópia impressa de um documento criado pela comunidade de desenvolvedores de Mozilla em 2015 – e corrigido sete anos depois. No entanto, a versão vulnerável também migrou para o Stack Overflow no closing de 2015. Embora o Snippet tenha recebido várias atualizações, a vulnerabilidade não foi fixada. De fato, o trecho de código ainda estava vulnerável a partir da publicação da pesquisa atual.
O mesmo aconteceu em 2016, observam os pesquisadores, com outra questão de transbordamento de pilha (com mais de 88.000 visualizações), nas quais um desenvolvedor suspeitava que o código possuía uma vulnerabilidade. No entanto, essa pessoa não foi capaz de verificar o problema; portanto, o código foi novamente assumido seguro.
Os pesquisadores suspeitam que o mal -entendido sobre a seriedade da vulnerabilidade é porque, quando os desenvolvedores testam o código, eles geralmente usam um navegador da internet ou o Linux’s Curl comando. Isso teria mascarado o problema. Os invasores, observam os pesquisadores, não são obrigados a usar clientes padrão.
Perturbando, os pesquisadores acrescentam: “Também encontramos vários cursos do Node.JS que usaram esse trecho de código vulnerável para fins de ensino”. .