Detalhes sobre os patches enviados pela Universidade de Minnesota revelados

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).


O conteúdo do artigo segue nossos princípios de Ética editorial. Para relatar um erro, clique Clique aqui.

Seja o primeiro a comentar

Deixe um comentário

Seu endereço de email não será publicado.

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.