Durante os últimos dias, o caso sobre as ações realizadas por um grupo de pesquisadores da Universidade de Minnesota, pois da perspectiva de muitos, tais ações em relação à introdução de vulnerabilidades no Kernel do Linux não têm justificativa.
E mesmo sendo um grupo Pesquisadores da Universidade de Minnesotpara publicar uma carta aberta de desculpas, cuja aceitação de mudanças no kernel Linux que foi bloqueado por Greg Kroah-Hartman revelou detalhes de patches enviados aos desenvolvedores do kernel e correspondência com os mantenedores associados a esses patches.
É digno de nota que todos os patches de problemas foram rejeitados Por iniciativa dos mantenedores, nenhum dos patches foi aprovado. Este fato deixa claro porque Greg Kroah-Hartman agiu tão duramente, já que não está claro o que os pesquisadores teriam feito se os patches tivessem sido aprovados pelo mantenedor.
Em retrospecto, argumentaram que pretendiam relatar o bug e eles não permitiriam que os patches fossem para o Git, mas não está claro o que eles fariam ou até onde poderiam ir.
No total, em agosto de 2020, cinco patches foram enviados dos endereços anônimos acostag.ubuntu@gmail.com e jameslouisebond@gmail.com (uma carta de James Bond): dois corretos e três incluindo erros ocultos, criando condições para o aparecimento de vulnerabilidades.
Cada patch continha apenas 1 a 4 linhas de código. A ideia principal por trás dos patches ruins era que consertar um vazamento de memória poderia criar uma condição para uma vulnerabilidade de liberação dupla.
O projeto visa melhorar a segurança do processo de patching no OSS. Como parte do projeto, estudamos problemas potenciais com o processo de patch de software de fonte aberta, incluindo as causas dos problemas e sugestões para solucioná-los.
Na verdade, este estudo revela alguns problemas, mas o seu objetivo é apelar a esforços para melhorar o
processo de patching para motivar mais trabalho para desenvolver técnicas para testar e verificar patches e, finalmente, para tornar o sistema operacional mais seguro.Com base nesses patches, resumimos seus padrões, estudamos os motivos específicos pelos quais os patches de introdução de bug são difíceis de detectar (com análises qualitativas e quantitativas) e, o mais importante, fornecemos sugestões para resolver o problema.
O primeiro patch problemático corrigiu o vazamento de memória adicionando uma chamada para kfree () antes de retornar o controle em caso de erro, mas criando condições para acessar a área da memória após sua liberação (use-after-free).
O patch especificado foi rejeitado pelo mantenedor, que identificou o problema e indicou que há um ano alguém já havia tentado propor uma mudança semelhante e ela foi inicialmente aceita, mas descartada no mesmo dia após a identificação das condições de vulnerabilidade.
O segundo patch também continha condições para o problema de desgaste pós-lançamento. O patch especificado não foi aceito pelo mantenedor, que rejeitou o patch devido a outro problema com list_add_tail, mas não percebeu que o ponteiro "chdev" pode ser liberado na função put_device, que é usada a seguir na chamada para dev_err (& chdev -> dev ..). No entanto, o patch não foi aceito, embora por motivos não relacionados à vulnerabilidade.
Curiosamente, inicialmente assumiu-se que 4 de 5 patches tinham problemas, mas os próprios pesquisadores erraram e em um patch problemático, em sua opinião, foi proposta a solução correta, sem as supostas condições de uso de memória após o lançamento.
Neste trabalho, apresentamos o conceito de «vulnerabilidade imatura» em que falta uma condição de vulnerabilidade, mas pode tornar-se real quando a condição é implícita
introduzido por um patch para outro bug.Também desenvolvemos ferramentas que nos ajudam a encontrar locais de código que podem sofrer
dos patches de introdução de bug e sugerir o que pode tornar esses patches de introdução de bug difíceis de detectar.Uma semana depois, informações foram enviadas aos desenvolvedores do kernel com uma proposta para discutir a possibilidade de promover vulnerabilidades sob o pretexto de correções triviais para vazamentos de memória, mas nada foi dito sobre as tentativas anteriores de enviar patches maliciosos.
O terceiro patch também foi rejeitado pelo mantenedor devido a outro bug sem vulnerabilidade (aplicação dupla em pdev).