{"id":99982,"date":"2021-04-21T22:23:44","date_gmt":"2021-04-21T20:23:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej"},"modified":"2021-04-21T22:23:44","modified_gmt":"2021-04-21T20:23:44","slug":"universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/universitet-minnesoty-otstranyon-ot-razrabotki-yadra-linux-za-otpravku-somnitelnyh-patchej","title":{"rendered":"La Universidad de Minnesota ha sido excluida del desarrollo del n\u00facleo Linux por el env\u00edo de parches sospechosos.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Greg Kroah-Hartman, encargado del mantenimiento de la rama estable del n\u00facleo de Linux, ha decidido prohibir la aceptaci\u00f3n de cualquier cambio en el n\u00facleo de Linux provenientes de la Universidad de Minnesota, as\u00ed como revertir todos los parches aceptados anteriormente y someterlos a una revisi\u00f3n nuevamente. La raz\u00f3n de la prohibici\u00f3n fue la actividad de un grupo de investigaci\u00f3n que estudia la posibilidad de introducir vulnerabilidades ocultas en el c\u00f3digo de proyectos abiertos. Este grupo envi\u00f3 parches que inclu\u00edan todo tipo de errores, observ\u00f3 la reacci\u00f3n de la comunidad y analiz\u00f3 formas de enga\u00f1ar el proceso de revisi\u00f3n de cambios. Seg\u00fan Greg, la realizaci\u00f3n de experimentos como este para introducir cambios maliciosos es inaceptable y poco \u00e9tica. <\/p>\n
La raz\u00f3n de la suspensi\u00f3n fue el env\u00edo por parte de los miembros de este grupo de un parche que a\u00f1ad\u00eda una verificaci\u00f3n de puntero para evitar posibles llamadas dobles a la funci\u00f3n \"free\". Dado el contexto de uso del puntero, la verificaci\u00f3n era innecesaria. El prop\u00f3sito del env\u00edo del parche era investigar si la modificaci\u00f3n err\u00f3nea pasar\u00eda la revisi\u00f3n por parte de los desarrolladores del n\u00facleo. Adem\u00e1s de este parche, surgieron otros intentos de desarrolladores de la Universidad de Minnesota de introducir cambios cuestionables en el n\u00facleo, incluyendo la adici\u00f3n de vulnerabilidades ocultas. <\/p>\n
El participante que envi\u00f3 los parches intent\u00f3 justificarse diciendo que estaba probando un nuevo analizador est\u00e1tico y que el cambio se prepar\u00f3 en base a los resultados de los an\u00e1lisis realizados. Pero Greg se\u00f1al\u00f3 que las correcciones propuestas no son caracter\u00edsticas de los errores detectados por los analizadores est\u00e1ticos y que todos los parches enviados no corrigen nada. Teniendo en cuenta que el grupo de investigadores en cuesti\u00f3n ya hab\u00eda intentado en el pasado promover correcciones con vulnerabilidades ocultas, es evidente que han continuado sus experimentos sobre la comunidad de desarrolladores del n\u00facleo. <\/p>\n
Es interesante que en el pasado el l\u00edder del grupo de experimentaci\u00f3n particip\u00f3 en la correcci\u00f3n leg\u00edtima de vulnerabilidades, por ejemplo, identific\u00f3 fugas de informaci\u00f3n en la pila USB (CVE-2016-4482) y en el subsistema de red (CVE-2016-4485). En el estudio sobre la promoci\u00f3n oculta de vulnerabilidades, el grupo de la Universidad de Minnesota menciona el ejemplo de la vulnerabilidad CVE-2019-12819, provocada por una correcci\u00f3n que se hab\u00eda aceptado en el n\u00facleo en 2014. La correcci\u00f3n a\u00f1ad\u00eda una llamada put_device al bloque de manejo de errores en mdio_bus, pero despu\u00e9s de cinco a\u00f1os sali\u00f3 a la luz que tal manipulaci\u00f3n conduce a acceder a un bloque de memoria despu\u00e9s de su liberaci\u00f3n (\"uso-despu\u00e9s-de-liberar\"). <\/p>\n
Sin embargo, los autores del estudio afirman que en su trabajo han generalizado datos sobre 138 parches que introducen errores y que no est\u00e1n relacionados con los participantes del estudio. Los intentos de enviar parches propios con errores se limitaron a una correspondencia por correo electr\u00f3nico, y tales cambios no fueron integrados en Git (si despu\u00e9s de enviar el parche por email el mantenedor lo consideraba normal, se le ped\u00eda que no incluyera el cambio debido a un error, despu\u00e9s de lo cual se enviaba un parche correcto). <\/p>\n
Adici\u00f3n 1: A juzgar por la actividad del autor del parche criticado, ya ha estado enviando parches a varios subsistemas del n\u00facleo desde hace tiempo. Por ejemplo, en los controladores radeon y nouveau se aceptaron recientemente cambios que llaman pm_runtime_put_autosuspend(dev->dev) en el bloque de errores, lo que podr\u00eda provocar el uso de un b\u00fafer despu\u00e9s de liberar la memoria asociada. <\/p>\n
Adendum 2: Greg revirti\u00f3 190 commits relacionados con direcciones \"@umn.edu\" y pidi\u00f3 su revisi\u00f3n nuevamente. El problema es que los participantes con direcciones \"@umn.edu\" no solo experimentaron con la promoci\u00f3n de parches cuestionables, sino que tambi\u00e9n solucionaron vulnerabilidades reales, y revertir los cambios puede dar lugar a la reaparici\u00f3n de problemas de seguridad previamente corregidos. Algunos mantenedores ya revisaron los cambios revertidos y no encontraron problemas, pero uno de los mantenedores se\u00f1al\u00f3 que hab\u00eda errores en uno de los parches que se le enviaron. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"