Greg Kroah-Hartman, quien es responsable de mantener la rama estable del kernel de Linux dio a conocer hace ya varios dias que tomo la decisión de negar cualquier cambio proveniente de la Universidad de Minnesota al kernel de Linux, y revertir todos los parches aceptados previamente 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, ya que este grupo ha enviado parches que incluyen errores de varios tipos.
Dado el contexto de uso del puntero, no tenía sentido y el propósito del envío del parche era investigar 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 para realizar cambios dudosos en el kernel, incluidos los relacionados con la adición de vulnerabilidades ocultas.
El colaborador que envió los parches intentó justificarse probando un nuevo analizador estático y el cambio se preparó en base a los resultados de la prueba 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 los parches enviados no solucionan nada. Dado que el grupo de investigadores en cuestión ya ha intentado en el pasado introducir soluciones con vulnerabilidades ocultas, está claro que han continuado sus experimentos en la comunidad de desarrollo del kernel.
Curiosamente, en el pasado, el líder del grupo de experimentación ha estado involucrado en correcciones de vulnerabilidades legítimas, como la filtración de información en la pila USB (CVE-2016-4482) y las redes (CVE-2016-4485).
En un estudio de propagación oculta de vulnerabilidades, el equipo de la Universidad de Minnesota cita un ejemplo de la vulnerabilidad CVE-2019-12819, causada por un parche que fue aceptado en el kernel en 2014. La solución agregó una llamada put_device al bloque de manejo de errores en mdio_bus, pero cinco años después se reveló que tal manipulación daría como resultado un acceso «use-after-free» al bloque de memoria.
Al mismo tiempo, los autores del estudio afirman que en su trabajo resumieron datos sobre 138 parches que introducen errores, pero que no están 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 la etapa de confirmación de Git en ninguna rama del kernel (si después de enviar el parche por correo electrónico, el mantenedor consideró que el parche era normal, entonces se le preguntó no incluir el cambio porque hay un error, después de lo cual se envió el parche correcto).
Además, a juzgar por la actividad del autor de la corrección criticada, ha estado enviando parches a varios subsistemas del kernel durante mucho tiempo. Por ejemplo, en los controladores radeon y nouveau se adoptaron recientemente cambios en la llamada pm_runtime_put_autosuspend (dev-> dev) errores en el bloque, es posible que lleve al uso de un búfer después de la liberación de la memoria asociada a ellos.
También se menciona que Greg revirtió 190 confirmaciones asociadas e inició una nueva revisión. El problema es que los colaboradores de @ umn.edu no solo experimentaron con la promoción de parches cuestionables, sino que también corrigieron vulnerabilidades reales, y revertir los cambios podría llevar al regreso de problemas de seguridad previamente arreglados. Algunos mantenedores ya han vuelto a comprobar los deshechos cambios y no encontró problemas, pero había también parches de errores.
El Departamento de Ciencias de la Computación de la Universidad de Minnesota emitió un comunicado anunciando la suspensión de la investigación en esta área, iniciando la validación de los métodos utilizados y realizando una investigación sobre cómo se aprobó dicha investigación. El informe de resultados se compartirá con la comunidad.
Finalmente Greg menciona que ha observado las respuestas de la comunidad y también a tomando en cuenta el proceso de explorar las formas de engañar al proceso de revisión. En opinión de Greg, realizar tales experimentos para introducir cambios dañinos es inaceptable y poco ético.
Fuente: https://lkml.org
from Desde Linux https://ift.tt/3nrsKlC
via IFTTT
No hay comentarios.:
Publicar un comentario