Trellix automatiza a correção de 62.000 projetos de código aberto vinculados a um bug do Python de 15 anos

A equipe de pesquisa da Trellix disse que corrigiu quase 62.000 projetos de código aberto que eram suscetíveis a uma vulnerabilidade de path traversal de 15 anos no ecossistema de programação Python.

A equipe identificou o bug, rastreado em CVE-2007-4559, no módulo tarfile do Python no final do ano passado. Foi relatado pela primeira vez ao projeto Python em 2007, mas não foi verificado. Desde então, sua presença se expandiu bastante, já que foi usado em aproximadamente 350.000 projetos de código aberto e inúmeros outros projetos de software proprietário ou de código fechado.

Para minimizar a área de vulnerabilidade, a equipe se inspirou na palestra DEFCON 2022 do pesquisador de segurança Jonathan Leitschuh sobre como corrigir vulnerabilidades em escala, passando meses conduzindo patches automatizados para fechar a vulnerabilidade em 61.895 projetos de código aberto, de acordo com uma postagem no blog Trellix de 23 de janeiro .

Como muitos projetos de código aberto carecem de equipe e recursos dedicados, patches em massa e patches automatizados podem ser uma ferramenta eficaz para diminuir a superfície de ataque. Embora ainda seja um conceito relativamente novo, com o primeiro grande aplicativo do mundo real introduzido por Leitschuh no ano passado, os pesquisadores da Trellix disseram à SC Media que seu patch bem-sucedido desta vez abre caminho para a comunidade de código aberto alavancar táticas semelhantes no futuro para melhorar defender seus projetos de exploração potencial.

“Embora leve tempo e exija colaboração, nosso esforço de correção em massa e automatizado diz ao setor que isso pode ser feito”, disse Kasimir Schulz, pesquisador de vulnerabilidades do Trellix Advanced Research Center.

Schulz disse que um dos maiores desafios ao usar uma abordagem automatizada é equilibrar a necessidade de corrigir o maior número possível de projetos sem diminuir a qualidade do patch. Para evitar o spam de projetos que não eram realmente vulneráveis, a equipe concentrou a ferramenta de verificação de código nos formatos de vulnerabilidade mais comuns.

Especificamente, o processo de patch da equipe pode ser dividido em duas etapas: a fase de patch e a fase de pull request, ambas automatizadas.

Durante a fase de correção, com a ajuda da entrega rápida de dados acionáveis ​​do GitHub , a equipe compilou uma lista exclusiva de repositórios a serem verificados rastreando uma lista de repositórios e arquivos contendo a palavra-chave “import tarfile”. Quando a lista foi entregue, a equipe usou o Creosote – uma ferramenta gratuita que eles construíram para os desenvolvedores verificarem se seus aplicativos são vulneráveis ​​– para determinar quais repositórios precisavam de correção. Assim que um repositório vulnerável foi identificado, a equipe corrigiu o arquivo e criou um diff de patch local para que os usuários pudessem comparar os dois arquivos.

A equipe então passou para a fase de pull request, primeiro revisando uma lista de diferenças de patch local e, em seguida, criando uma bifurcação do repositório no GitHub. Depois de clonar o fork, eles substituíram o arquivo original pelo arquivo corrigido se o arquivo original não tivesse mudado.

“Em seguida, confirmamos as alterações no repositório e criamos uma solicitação pull de nosso repositório bifurcado de volta ao repositório original, juntamente com uma mensagem detalhando quem éramos e por que estávamos fazendo a solicitação pull. Nesse ponto, cabia ao proprietário do repositório aceitar ou rejeitar nossas alterações”, explicou a postagem do blog.

Patching automatizado é uma espada larga, não um bisturi

Embora o sucesso da Trellix possa servir de modelo para a comunidade mais ampla de código aberto, os pesquisadores de segurança dizem que a correção massiva e automatizada vem com seu próprio conjunto de desafios e riscos de segurança.

“Acho que a abordagem de correção automatizada adotada pelos pesquisadores da Trellix é extremamente útil, mas temo que só possa ser praticada em situações específicas, como a descrita na postagem do blog em que as condições para a vulnerabilidade a ser aplicável são muito bem definido”, disse Yotam Perkal, diretor de pesquisa de vulnerabilidade da Rezilion.

Um risco é que o patch automatizado em escala pode funcionar mais como uma espada larga do que como um bisturi, que pode ser menos eficaz dependendo do ambiente de TI específico.

“Seria ideal se um pesquisador pudesse definir uma consulta CodeQL que identificasse um padrão de código vulnerável específico sem gerar muito ruído [ou] detecções falsas”, disse Perkal. No entanto, ele observou que a criação de tal consulta não é direta, pois muitas vezes várias condições lógicas devem estar em vigor para que um padrão de código vulnerável seja explorável.

O teste é outro desafio com patches em massa. Muitas vezes, em vez de apenas corrigir algo e esperar que não cause danos, os pesquisadores testam o software após um patch para garantir que nada esteja quebrado e a atualização realmente mitigue o problema real, disse Tim Mackey, chefe de estratégia de risco da cadeia de suprimentos de software da Synopsys. .

“Se as salvaguardas de teste apropriadas estiverem em vigor, a correção em massa oferece uma promessa significativa para aliviar as vulnerabilidades legadas”, disse Mackey. “Se alguém pensa que isso pode ser feito com uma simples substituição de string de ‘versão ruim’ por ‘versão boa’, sem investir em testar os resultados do esforço, provavelmente criará mais danos do que benefícios.”