Acabamos de informar sobre registro de cambios de Linux 5.12 con un enfoque en los objetivos de Arm, MIPS y RISC-V el martes, y en ese momento, la expectativa era una demora de aproximadamente una semana después de que Linux 5.12-rc8 se publicara el domingo. 18 de abril.
Pero Linux 5.12 podría retrasarse aún más debido a las travesuras de dos Ph.D. estudiantes que realizan un proyecto de investigación sobre vulnerabilidad de código abierto en la Universidad de Minnesota. Esto fue anunciado por Greg Kroah-Hartman en la lista de correo del kernel de Linux.
Se ha encontrado que las confirmaciones de las direcciones @ umn.edu se envían de «mala fe» para intentar probar la capacidad de la comunidad del kernel para revisar cambios «maliciosos conocidos». El resultado de estas presentaciones se puede encontrar en un artículo publicado en el 42º Simposio de IEEE sobre seguridad y privacidad titulado «Inseguridad de código abierto: introducción sigilosa de vulnerabilidades a través de compromisos hipócritas»
Así que su trabajo se revertirá con 190 reversiones hasta ahora. También significa que las confirmaciones futuras de la Universidad de Minnesota serán rechazadas desde la línea principal de Linux de forma predeterminada.
Encontrará el artículo de investigación alojado en Github. El documento de investigación menciona que los objetivos de los «compromisos hipócritas» incluyen grandes proyectos que aceptan compromisos de terceros, incluido el kernel de Linux, Android, FreeBSD, Firefox, Chromium, OpenSSL y otros. Pero parece que su experimento de prueba de concepto solo apunta al kernel de Linux usando vulnerabilidades UAF (use-after-free) ya que identificaron más de «vulnerabilidades UAF inmaduras de 6K en el kernel de Linux que potencialmente pueden convertirse en vulnerabilidades reales».
El documento también implica que lo hicieron de manera ética e informaron a los mantenedores tan pronto como se confirmó uno de sus conjuntos de parches.
Nuestro objetivo no es introducir vulnerabilidades para dañar el OSS. Por lo tanto, realizamos el experimento de manera segura para asegurarnos de que el UAF introducido no se fusionará con el código de Linux real
…
Una vez que un mantenedor confirmó nuestros parches, por ejemplo, un correo electrónico «se ve bien», notificamos inmediatamente a los mantenedores del UAF introducido y les pedimos que no apliquen el parche.
…
Todos los parches de introducción de UAF se quedaron solo en los intercambios de correo electrónico, sin siquiera convertirse en un compromiso de Git en las sucursales de Linux. Por lo tanto, nos aseguramos de que ninguno de nuestros errores UAF introducidos se fusionara en ninguna rama del kernel de Linux, y ninguno de los usuarios de Linux se vería afectado
También escribieron que señalan el error a los encargados del mantenimiento y proporcionan los parches correctos. Pero después de leer el correo electrónico de Greg KH, no creo que él comparta el mismo sentimiento. Podría deberse a una falta de comunicación, simplemente no lo sabemos en este momento.
Evaluar la seguridad de los proyectos de código abierto es una iniciativa encomiable, pero las pruebas son ciertamente un problema, ya que no se puede hacer informando a los mantenedores que está a punto de introducir «compromisos hipócritas» de antemano. No sé la respuesta correcta, pero si cree que sí, no dude en comentar a continuación.
Traducido del artículo en inglés «PhD students willfully committed known malicious changes to mainline Linux«.
Publicaciones traducidas automáticamente