Universidad de Minnesota suspendida del desarrollo del kernel de Linux por enviar parches cuestionables

Greg Kroah-Hartman, responsable del mantenimiento de la rama estable del kernel de Linux, decidió prohibir la aceptación de cualquier cambio proveniente de la Universidad de Minnesota en el kernel de Linux, así como revertir todos los parches previamente aceptados y volver a revisarlos. El motivo del bloqueo fueron las actividades de un grupo de investigación que estudia la posibilidad de promover vulnerabilidades ocultas en el código de proyectos de código abierto. Este grupo envió parches que contenían varios tipos de errores, observó la reacción de la comunidad y estudió formas de engañar al proceso de revisión de cambios. Según Greg, realizar experimentos de este tipo para introducir cambios maliciosos es inaceptable y poco ético.

El motivo del bloqueo fue que los integrantes de este grupo enviaron un parche que agregaba un check de puntero para eliminar la posible doble llamada de la función “gratuita”. Dado el contexto del uso del puntero, la verificación fue inútil. El propósito de enviar el parche era ver si el cambio erróneo pasaría la revisión de los desarrolladores del kernel. Además de este parche, han surgido otros intentos de desarrolladores de la Universidad de Minnesota de realizar cambios dudosos en el kernel, incluidos aquellos relacionados con la adición de vulnerabilidades ocultas.

El participante que envió los parches intentó justificarse diciendo que estaba probando un nuevo analizador estático y que el cambio se preparó en base a los resultados de las pruebas en él. Pero Greg llamó la atención sobre el hecho de que las correcciones propuestas no son típicas de los errores detectados por los analizadores estáticos, y todos los parches enviados no solucionan nada en absoluto. Dado que el grupo de investigación en cuestión ha intentado implementar parches para vulnerabilidades ocultas en el pasado, está claro que han continuado sus experimentos con la comunidad de desarrollo del kernel.

Curiosamente, en el pasado, el líder del grupo que realizó los experimentos participó en parches legítimos de vulnerabilidades, por ejemplo, identificando fugas de información en la pila USB (CVE-2016-4482) y el subsistema de red (CVE-2016-4485). . En un estudio sobre la propagación sigilosa de vulnerabilidades, un equipo de la Universidad de Minnesota cita el ejemplo de CVE-2019-12819, una vulnerabilidad causada por un parche del kernel lanzado en 2014. La solución agregó una llamada a put_device al bloque de manejo de errores en mdio_bus, pero cinco años más tarde surgió que dicha manipulación conduce al acceso al bloque de memoria una vez liberado (“use-after-free”).

Al mismo tiempo, los autores del estudio afirman que en su trabajo resumieron datos de 138 parches que introdujeron errores y no estaban relacionados con los participantes del estudio. Los intentos de enviar sus propios parches con errores se limitaron a la correspondencia por correo electrónico, y dichos cambios no llegaron a Git (si, después de enviar el parche por correo electrónico, el mantenedor consideró que el parche era normal, entonces se le pidió que no incluyera el cambio ya que fue un error, tras lo cual enviaron el parche correcto).

Adición 1: A juzgar por la actividad del autor del parche criticado, lleva mucho tiempo enviando parches a varios subsistemas del kernel. Por ejemplo, los controladores radeon y nouveau adoptaron recientemente cambios con una llamada a pm_runtime_put_autosuspend(dev->dev) en un bloque de error, lo que posiblemente provocó que se use el búfer después de liberar la memoria asociada a él.

Anexo 2: Greg revirtió 190 confirmaciones asociadas con "@umn.edu" e inició una nueva revisión de ellas. El problema es que los miembros con direcciones "@umn.edu" no sólo han experimentado con parches cuestionables, sino que también han parcheado vulnerabilidades reales, y revertir los cambios podría resultar en que regresen los problemas de seguridad previamente parcheados. Algunos mantenedores ya volvieron a verificar los cambios revertidos y no encontraron problemas, pero uno de los mantenedores indicó que uno de los parches que le enviaron tenía errores.

Fuente: opennet.ru

Añadir un comentario