Linus Torvalds activa el “modo centinela” de Linux: “Activamente maliciosa”

Las distribuciones de Linux como Ubuntu son opciones seguras y ligeras, por lo que se han posicionado con buenas alternativas para Windows 11. Sin embargo, detrás de todos estos sistemas, está el kernel de Linus Torvalds como base, el cual se actualiza recurrentemente y un equipo gigante trabaja para que se realicen los cambios necesarios adecuadamente.

Uno de los integrantes es Kees Cook, un desarrollador que se enfoca en la protección del sistema y lidera el área de Kernel Self-Protection Project (KSPP). Esto quiere decir, que trabaja directamente con la corrección de vulnerabilidades y defensas contra los ataques.

Sin embargo, recientemente ha surgido un malentendido que ha levantado las alertas del rey del Pingüino Tux, aunque es algo que puede suceder cuando hay una gran cantidad de personas realizando modificaciones en un proyecto masivo como este, pero esta vez ha sido tan sospechoso que se pensaba que de verdad parecía una medida “activamente maliciosa”.

330 solicitudes de extracción fueron registradas como “malignas” por replicar código de Torvalds 

El acontecimiento en cuestión ha llamado la atención tanto de los desarrolladores, como de los usuarios, ya que se ha generado cierta tensión en el equipo tras el envío de 330 solicitudes de extracción (pull requests) que se consideraron sospechosas por su integración.

Lo que se hizo con estos elementos que provenían de Kees Cook es que se categorizaron como códigos duplicados de parches que había hecho Torvalds. Aquí el desarrollador principal había sido incluido como autor de manera “falsa”, mientras que las firmas SHA-1 no eran iguales a las originales, lo cual indicaba que podrían haber sido modificadas de alguna manera.

La real era “9d230d500b0e” y la réplica era “f8b59a0f90a2”, tal y como se puede apreciar en las páginas compartidas. El problema escaló hasta un punto en el que Linus lo llamó como una acción “activamente maliciosa” y se notaba desconfiado sobre la explicación con al que se defendió Kees Cook, quien afirmaba que todo se debía a que su disco duro SSD se había dañado de alguna manera.

Los defectos del mencionado componentes hicieron que los datos fueran corrompidos y se generaran fallos en vez de que se enviaran las solicitudes de forma correcta. Considerando esto, el rey del Pingüino Tux lo categorizó como una posible automatización o scripting involuntario.

“Tuve una falla en mi SSD, pero las cosas parecían estar bien después de eso, pero luego, cuando construí el árbol for-linus/hardening, volví a basar los parches que estaban encima de for-next y pasé al último ‘master’ porque basarlo en un rc3 pasado parecía extraño. Fue por aquí donde empecé a tener problemas”. — Kees Cook.

Cook se disculpó por lo sucedido diciendo que “no lo hice a propósito” y borró todo el árbol de parches afectado para reconstruirlo y lograr hacer que todo el proceso vuelva a ejecutarse sin crear errores como el reciente. 

Tras varios análisis, ambos, junto a Konstantin Ryabitsev (administrador de kernel.org) pudieron dar con el origen del inconveniente, el cual era la herramienta B4 que reescribió todos los metadatos de manera incorrecta en el historial y por eso aparecieron estos malos entendidos.

No es la primera vez que pasa algo como esto, ya que ha habido otras equivocaciones, como el código basura de la versión 6.15-rc1 que lo enfureció o el día que se le olvidó lanzar la 6.14. Estas son unas de las cosas que confirman que desarrollar este proyecto es más complicado de lo que parece.

Sea como sea, se nota que solo ha sido un fallo técnico que ha ocasionado muchas interrogantes. De igual manera, al ver cómo ha actuado Linus Torvalds ante el incidente, los usuarios pueden estar tranquilos porque a pesar de que la seguridad no es su área concreta, siempre está pendiente como un centinela para prevenir que cualquier problema afecte al kernel de Linux.

Otros artículos interesantes: