Os detalles sobre os parches presentados pola Universidade de Minnesota revelaron

Durante os últimos días o caso sobre as accións realizadas por un grupo de investigadores da Universidade de Minnesota, xa que desde a perspectiva de moitos, tales accións en relación coa introdución de vulnerabilidades no núcleo Linux non teñen xustificación.

E aínda que un grupo Investigadores da Universidade de Minnesotapublicar unha carta aberta de desculpa, cuxa aceptación de cambios no núcleo Linux bloqueado por Greg Kroah-Hartman revelou detalles de parches enviados aos desenvolvedores do núcleo e correspondencia cos mantedores asociados a estes parches.

Chama a atención que rexeitáronse todos os parches de problemas Por iniciativa dos mantedores, ningún dos parches foi aprobado. Este feito deixa claro por que Greg Kroah-Hartman actuou con tanta dureza, xa que non está claro que farían os investigadores se os parches foran aprobados polo mantedor.

Retrospectivamente, argumentou que pretendían denunciar o erro e non permitirían que os parches fosen a Git, pero non está claro que farían ou ata onde poderían chegar.

En total, en agosto de 2020, enviáronse cinco parches desde os enderezos anónimos acostag.ubuntu@gmail.com e jameslouisebond@gmail.com (unha carta de James Bond): dous correctos e tres incluíndo erros ocultos, creando condicións para a aparición de vulnerabilidades.

Cada parche contiña só de 1 a 4 liñas de código. A idea principal detrás dos parches incorrectos era que solucionar unha fuga de memoria podería crear unha condición para unha dobre vulnerabilidade gratuíta.

O proxecto ten como obxectivo mellorar a seguridade do proceso de parcheo en OSS. Como parte do proxecto, estudamos os posibles problemas co proceso de parches OSS, incluíndo as causas dos problemas e suxestións para solucionalos.

De feito, este estudo revela algúns problemas, pero o seu obxectivo é pedir esforzos para mellorar o
proceso de parches para motivar máis traballo para desenvolver técnicas para probar e verificar parches e, finalmente, para facer o sistema operativo máis seguro.

Baseado nestes parches, resumimos os seus patróns, estudamos as razóns específicas polas que os parches de introdución de erros son difíciles de atrapar (cunha análise cualitativa e cuantitativa) e, sobre todo, ofrecemos suxestións para solucionar o problema.

O primeiro parche problemático solucionou a fuga de memoria engadindo unha chamada a kfree () antes de devolver o control en caso de erro, pero creando condicións para acceder á área de memoria despois de ser liberada (use-after-free).

O mantemento rexeitou o parche especificado, que identificou o problema e indicou que hai un ano alguén xa intentou propoñer un cambio similar e inicialmente foi aceptado, pero descartado o mesmo día despois de identificar as condicións de vulnerabilidade.

O segundo parche tamén contiña condicións para o problema de desgaste posterior ao lanzamento. O mantemento especificado non foi aceptado polo mantedor, que rexeitou o parche debido a outro problema con list_add_tail, pero non se decatou de que o punteiro "chdev" pode liberarse na función put_device, que se usa a continuación na chamada a dev_err (& chdev -> dev ..). Non obstante, o parche non foi aceptado, aínda que por motivos non relacionados coa vulnerabilidade.

curiosamente, inicialmente supúxose que 4 de cada 5 parches tiñan problemas, pero os propios investigadores cometeron un erro e, na súa opinión, propúxose a solución correcta nun parche problemático, sen as supostas condicións para usar a memoria despois do lanzamento.

Neste traballo, presentamos o concepto de «vulnerabilidade inmatura» onde falta unha condición de vulnerabilidade, pero pode converterse nunha verdadeira cando a condición está implicitamente
introducido por un parche para outro erro.

Tamén desenvolvemos ferramentas que nos axudan a atopar lugares de código que poden sufrir
dos parches de introdución de erros e suxire que pode facer que estes parches de introdución de erros sexan difíciles de detectar.

Unha semana despois, enviouse información aos desenvolvedores do kernel cunha proposta para discutir a posibilidade de promover vulnerabilidades baixo o disfrace de triviais correccións de fugas de memoria, pero non se falou nada dos intentos anteriores de enviar parches maliciosos.

O terceiro parche tamén foi rexeitado polo mantedor debido a outro erro sen vulnerabilidade (dobre aplicación en pdev).