Durante los últimos dias se ha estado discutiendo el caso sobre las acciones que tomaron un grupo de investigadores de la Universidad de Minnesota, ya que desde la perspectiva de muchos, dichas acciones en relación de la introducción de vulnerabilidades en el Kernel de Linux no tiene justificación.
Y a pesar de que un grupo de investigadores de la Universidad de Minnesota publicaran una carta abierta de disculpa, cuya aceptación de cambios al kernel de Linux que fue bloqueada por Greg Kroah-Hartman, reveló detalles de los parches enviados a los desarrolladores del kernel y la correspondencia con los mantenedores asociados con estos parches.
Es de destacar que todos los parches problemáticos fueron rechazados por iniciativa de los mantenedores, ninguno de los parches fue aprobado. Este hecho deja en claro por qué Greg Kroah-Hartman actuó con tanta dureza, ya que no está claro qué habrían hecho los investigadores si los parches hubieran sido aprobados por los encargados del mantenimiento.
En retrospectiva, argumentaron que tenían la intención de informar del error y no permitirían que los parches fueran a Git, pero no está claro qué harían realmente o qué tan lejos podrían llegar.
En total, en agosto de 2020, se enviaron cinco parches desde las direcciones anónimas acostag.ubuntu@gmail.com y jameslouisebond@gmail.com (una carta de James Bond): dos correctos y tres que incluyen errores ocultos, creando condiciones para la aparición de vulnerabilidades.
Cada parche contenía solo de 1 a 4 líneas de código. La idea principal detrás de los parches erróneos era que arreglar una fuga de memoria podría crear una condición para una vulnerabilidad libre doble.
El proyecto tiene como objetivo mejorar la seguridad del proceso de parcheo en OSS. Como parte del proyecto, estudiamos problemas potenciales con el proceso de parcheo de OSS, incluidas las causas de los problemas y sugerencias para dirigiéndose a ellos.
De hecho, este estudio revela algunos problemas, pero su objetivo es pedir esfuerzos para mejorar la
proceso de parcheo para motivar más trabajo que desarrolle técnicas para probar y verificar parches, y finalmente para hacer que el OS sea más seguro.Basado en estos parches, resumimos sus patrones, estudiamos las razones específicas por las que los parches de introducción de errores son difíciles de captura (con un análisis tanto cualitativo como cuantitativo) y, lo que es más importante, proporcionar sugerencias para abordar el problema.
El primer parche problemático solucionó la pérdida de memoria agregando una llamada a kfree() antes de devolver el control en caso de un error, pero creando condiciones para acceder al área de memoria después de que se liberó (use-after-free).
El parche especificado fue rechazado por el mantenedor, quien identificó el problema e indicó que hace un año alguien ya había intentado proponer un cambio similar y fue inicialmente aceptado, pero descartado el mismo día después de identificar las condiciones de la vulnerabilidad.
El segundo parche también contenía condiciones para el problema de uso después de la liberación. El parche especificado no fue aceptado por el mantenedor, quien rechazó el parche debido a otro problema con list_add_tail, pero no notó que el puntero «chdev» se puede liberar en la función put_device, que se usa a continuación en la llamada a dev_err (& chdev -> dev ..). Sin embargo, el parche no fue aceptado, aunque por razones ajenas a la vulnerabilidad.
Curiosamente, inicialmente se asumió que 4 de cada 5 parches tenían problemas, pero los propios investigadores cometieron un error y en un parche problemático, en su opinión, se propuso la solución correcta, sin las supuestas condiciones para usar la memoria después del lanzamiento.
En este trabajo, presentamos el concepto de «vulnerabilidad inmadura» donde un falta su condición de vulnerabilidad, pero puede convertirse en una real cuando la condición es implícitamente
introducido por un parche para otro error.También desarrollamos herramientas que nos ayudan a encontrar lugares de código que pueden sufrir
de los parches de introducción de errores y sugiera qué puede hacer que estos parches de introducción de errores sean difíciles de detectar.Una semana después, se envió información a los desarrolladores del kernel con una propuesta para discutir la posibilidad de promover vulnerabilidades bajo la apariencia de correcciones triviales para fugas de memoria, pero no se dijo nada sobre intentos anteriores de enviar parches maliciosos.
El tercer parche también fue rechazado por el mantenedor debido a otro error sin vulnerabilidad (doble aplicación en pdev).